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I . EXECUTIVE SUMMARY 



A. PURPOSE 



The purpose cf this study is to assess the impact or 
Large Scale Integration (LSI) of electronic circuits with 
respect to future airborne digital systems. Although the 
findings are applicable to any airborne system, the focus of 
this study is the VSTOL aircraft projected for development 
and production in the 1985 time frame. 



E. SCOPE 



The study addresses the design, implementation, testing, 
servicing and the associated life cycle ccsts of airborne 
digital computer systems, both the hardware and the pregrams 
necessary for successful operation of the system. The scope 
cf the study is limited strictly to the digital computer 
systems and does not include the sensors, which provide the 
data, the displays, keyboards, and switches which provide 
the human interface, or the effectors which help carry out 
the actions of the system. 
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OBJECTIVE 



The study provides information for 
the future course of action in 
electronic circuit industry. The st 
design philcsosphy, an analysis me 
program design, and a life cycle 
applicable to similar studies. 



decision making on 
the highly volatile 
udy also provides a 
thodolcgy useful for 
cost analysis method 



E. METHCE OF APPROACH 



The study first explores the implications of 
technological changes which are brougnt about by Large 
Integration. Although the technological changes rel 
nardware, these changes imply corresponding chang 
system architectures and programming. One of the 
important cost components is the software design. The 
describes a set of software design principles 
emphasizes uniformity, homogeneity, and a testable d 
The design principles are applicable particularl 
tactical systems which are known to be complex and dif 
to test. 



the 
Scale 
ate to 
es in 
most 
study 
which 
esign. 
y to 
f icult 



He separate the software design 
implementation. The software design can b 
without committment to a specific computer 
operational programs can be developed ar. 
developmental systems which are specifica 
program development. 



from hardware 
e carried out 
hardware. The 
d tested on 
lly suited for 



Software design. 



implementation and testing is a time 
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consuming process and in major systems takes years to 
develop. Decisions on which computer hardware to use can be 
made at a point in time near the end of the development 
cycle. This insures an up-to-date hardware implementation 
and an improved transferability cf software products. 

*ie see two major trends in airborne system's 
architectures. These alternatives fcr hardware 
implementaticn are: the homogeneous and the heterogeneous 
systems. The homogeneous system consists of a collection of 
computers each of which is functionally identical. The 
heterogeneous systems contain at least twc functionally 
different types cf computers: the "mission computers" and 
the "embedded" computers. 

In crder to develop a life cycle cost analysis fcr the 
two majcr design alternatives, we first develop the 
projected functional requirements for the VSTOL (attack 
version) tactical system. Because the functional 
requirements of VSTOL will be similar tc the presently 
operational attack aircraft, A6-E, we study the A6-E in 
great detail. From the detailed data we can estimate wcrst 
case execution times, the number of variables shared by 
processes, the number of instructions, constants and 
variables in the programs. Ey knowing the execution times 
for particular instructions on a given computer, we can 
estimate the execution times of program segments executed on 
that computer. 

From this data we can compare the homogeneous and 
heterogeneous implementation alternatives for the A6-E, or 
for a projected system such as the VSTOL . The life cycle 
cost estimate is developed for the alternatives. 

Based on the analysis of the Ao-E system, it is 
established that presently marketed LSI computers can be 
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used to implement the 
which use presently 
cost comparisons into 
scenarious and three 
the "optimistic", and 



systems. We develop cost comparisons 
available cost data. We project the 
the 1985 timeframe by structuring two 
cases within each: the "most likely", 

the "pessimistic". 



E. II A JO E FINDINGS 



1 . The Software Aguis it ion C ost 

When we discuss the cost of software, we distinguish 
between software development costs and software aguisition 
costs. Ihe development is a "human intensive" activity and 
its cost is high in comparison to production costs of LSI 
circuits. Although program development costs are variable, 
the variability is generally bounded by $5 - $60 per 

instruction. The program aguisition cost is dependent on 
the number of potential users of the program. Software 
development tools such as editors, assemblers, compilers, 
decuggers and operating systems can be bought for $30 - 
$1000 per program. The aguisition cost per instruction for 
widely used programs ranges from $.001 - $.02, about three 
to four orders of magnitude different from the program 
production costs. Therefore custom built software, which is 
exclusively designed for the Navy (CHS -2 compilers, AN/UYK-7 
operating systems, AN/UYK-20 operating systems) is high in 
aguisition cost in comparison to widely used compilers and 
operating systems. To minimize software costs it is 

important to avoid custom built software as much as 

possible . 

2 • The Har dw are A guisit ion Cost 
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We again distinguish between hardware development 
costs and hardware aguisition costs. Hardware design and 
development is a '•human intensive" process, hence the design 
and development cost is high. The hardware aguisiticn cost 
varies widely. If a distributed computer system is built 
from modular LSI single board computer systems which are 
widely used, the aguisition cost per computer is in the 
range from $500 - $2000. If the computer is a custom 
design, the price per computer, even if LSI chips are used 
in the design, jumps tc the range $20,000 - $50,000. To 
minimize aguisition costs it is important to avoid custom 
designs and custom built hardware as much as possible. In 
the highly competitive LSI hardware market, the widely used 
hardware aguisition costs are likely to drop and make the 
future cost differential between custom designs and widely 
accepted designs even greater. 



3. The Software Ma inten ance Costs 

Changes in software have an extremely high ccst per 
instruction. Literature guotes a range from $500 - $8000 
per instruction. The cost is dependent on bcw modular the 
programs are, how well they are documented, the complexity 
of programs, the language used, etc. 

Any errors in the program which pass the acceptance 
tests are particularly expensive because the maintainers 
have tc become as familiar with the program as the 
originators. Exhaustive acceptance tests, on the ether 
hand, are impossible to conduct (There are approximately 
10 64 possible program paths in the A6-E program) . Modular 
design and thorough module testing is the way to achieve 
success. 
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Tne cost differential oetween homogeneous and 
heterogeneous systems for maintenance and update of software 
depends on the languages used to construct the software. If 
only a single higher level language is used, the cost 
differential is small. Assumed here is that the higher 
level language compiler aguisiticn cost has teen included in 
the software aguisition cost. If assembly languages are 
permitted, the educational cost of software maintainers will 
vary in proportion to the number of distinct computer types 
used in the system. 



4. The hardware Maintenance Cost 



I 

hcmogenec 
education 
to the nu 
procedur e 
propcrtic 
Ihe spare 
system, 
these co 
computers 



he hardware maintenance cost dif 
us and heterogeneous systems 
al costs of maintenance personnel 
mber of distinct computers in the 
s and test programs necessary 
n with the number of distinct co 
parts inventory, the paperwor 
and the documentation at the rep 
sts are multiplied by the nu 
in the system. 



ferential between 
is large. The 
are proportional 
system. The test 
vary in direct 
mpcnent computers, 
k in the supply 
air facility - all 
mber of distinct 



Cost Summary Pro jection 
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presently existing systems are: Digital Equipment 
Corporation's LSI11, INTEL'S 8080, Texas Instruments' 9900 
family. 



The heterogeneous alternative consists of a 
so-called "mission computer" surrounded by a variety of 
possibly distinct sensor embedded LSI computers which act as 
pre-processors to the system. The system is connected by a 
time-multiplexed data bus, such as the military standard 
1553. Present examples are the F-15, and the F-18 tactical 
systems . 



The hardware costs are substantially affected by the 
passage of time, hence they are estimated for 1977 and 1985 
to illustrate that the advantage to the homogeneous system 
becomes even greater as time passes. The software costs 
illustrated are based on the navigation, ballistics, and 
command modules abstracted in this report from the A6-E 
operational flight program. While not a complete picture of 
the VSTCL operational flight program, since that program is 
not yet specified, it does provide a reasonable 
representation of the core set of computations common across 
all VSTOL variants. 
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that the 



estimated 



iigure I. 1 shows that the estimated software 
aguisition costs dc not differ substantially in the two 
alternatives. There are uncertainties dependent on the 
aguisition strategy. If the Navy special language CMS- 2 is 
a requirement for all programs, including embedded processor 
programs, then a CMS-2 compiler would have to be written for 
each computer. We assume that this will not be done and 
that a variance will be granted for the periferal computers. 
If a widely used higher level language (FORTRAN, BASIC) is 
permitted, a relatively small aguisition cost is associated 
with the compilers for the LSI computers. 



The differences between the hcmogenecus and 
heterogeneous alternatives are greater for the hardware 
aguisition ccst estimates. A special purpose design fcr the 
Navy cannot te cost-shared and hence the hardware aguisition 
ccst for the "mission" computer is high ($50,000) . The 
embedded computers are low cost items if no uniformity 
requirements are imposed and each subcontractor uses "his 
own" favorite embedded computer. In the nomogeneous 
alternative embedded computers must be identical, hence a 
higher aguisition cost is required if the embedded systems 
must be redesigned. The estimated hardware aquisiticn ccsts 
for the heterogeneous system is nevertheless higher. 

The software maintenance cost estimate is higher for 
the Heterogeneous system. The cost difference is greater if 
assembly language programs are used in the embedded 
computers . 



Ihe hardware maintenance cost estimate has the 
largest difference between the homogeneous and heterogeneous 
alternatives. If the hardware reliability is as high as is 
expected, then the total estimated maintenance cost will be 
lower than cur present experience indicates. The difference 
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in total costs between the design alternatives will 
therefore be less pronounced than shown in Figure 1.1. 



Not included in 


this 


summary 


but specified 


in 


Chapter IX is the additional 


cost 


of aircr 


aft overdesign 


for 


the extra weight inherent 
heterogeneous alternative. 


in 
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mission 


computer of 
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Ihe total cost estimate comparis 
system's alternatives shows that the homoge 
substantial advantages over the heterogenec 
However, to carry out the homogeneous 
requires a high degree of discipline and cco 
contractors, subcontractors and the Navy 
Eecause projects are funded on the basis of 
rather than lifecycle costs, the homogen 
show its advantages during the aguisition ph 
of the cost differential will appear during 
phase . 
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II . 



INTRODUCTION 



A . BACKGROUND 



Although analog devices which might fce called analog 
computers have been used in airborne applications for a long 
time, digital computers have been used only recently, in the 
late 1960's and early 1970's. The Navy attack aircraft A6-E 
and A7-Z have a comprehensive tactical system based on a 
general purpose digital computer. The antisubmarine warfare 
aircraft, the P3-C and S3-A, the radar surveillance 
aircraft, E2-C, and the electronic warfare aircraft E6-E all 
depend cn a general purpose digital computer system as a 
vital part of the weapons system. Because of decreasing 
costs, weights, and power requirements and increasing 
reliability and capability of digital electronics, the trend 
toward mere use of digital technology is clear. 

There is also an observable trend in the system's 
architecture of the Navy's presently acquired systems. The 
f-18 typifies the concept of the tactical system consisting 
of a central "mission computer," a dual CPU AN/UYK-14, which 
is the so called airborne Navy "standard" computer, 
surrounded by a distributed set of "embedded" computers, 
each of which is dedicated to some fixed functional task 
such as navigation, flight control, or fire control. The 
"mission" computers together with the "embedded" computers, 
which may be different from each other, make up a 
"heterogeneous" digital system. 
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In light of tne rabidly changing Large Scale Integration 
(LSI) technology, there are numerous choices to implement 
future airborne systems. Which choice is made will have 
important consequences in cost, weight, reliability, and 
capability. Ihis study addresses two major alternatives of 
system's implementation: the homogeneous alternative 
consisting of a system of functionally identical processing 
elements connected into a regular network; the hetercgeous 
alternative which contains a central "mission computer" with 
a mix of "embedded" processing elements connected into a 
network by a serial time multiplex data bus, such as the 
MLSTD 1553 (£) . 

The technical feasibility of the homogeneous alternative 
is subject to question, because there is a belief that the 
currently available LSI processing elements are too slew and 
too small to carry out the tasks demanded by a real time 
tactical system. A substantial part of this report is 
devoted to establishing the technical feasibility of the 
hcmogenecus alternative. 

Several reports have addressed the implementation of 
tactical systems using LSI processing elements. The 
Honeywell report [13] represents a view which anticipates 
that the airborne computing will soon become distributed 
among identical LSI processors which are connected by a data 
bus of high data rate. The report recommends that we 
proceed with laboratory models instead of paper studies. 
Although the study anticipates microprocessors of some 
capability, the authors in 1973 did not anticipate the 
powerful single chip computers available in 1977. 

Texas Instruments, [4] produced a report in 1975, which 
accurately projected the availanility of 16 bit 
microcomputers with multiply and divide functions executed 
at the speeds which are realized in 1977. Their analysis 
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accurately projects costs, develops design methodolcgy for 
distributing computing among a collection of 20 
independently operating processors connected by a local bus 
into affinity groups. The affinity groups in turn are 
connected by a global bus to form the tactical system. The 
report includes analysis and design tools which are worked 
cut in great detail and provide a designer with useful tools 
tc implement a tactical system with presently available 
computers. Iheir report clcsely parallels the analysis 
fcund in this report. 

A report by McDonnell-Do uglas [9] represents the view 
that a central mission computer, surrounded by the special 
purpose computers is the preferred design. Distributing the 
processes among many small computers creates reliability 
problems, according to their report. 

Sperry Univac study [8] concerns itself mere with design 
methcdolcgy rather than any particular implementation. Tne 
methodology suggests a series of seven steps which tends to 
separate the software design from the hardware 
implementation . The operational flight program is designed 
in terms of decomposit ional units which are at the final 
stages of design mapped into hardware or firmware. 

A more general report which addresses the tactical 
computer needs not only for airborne computers but tactical 
systems used in the Army and Navy, was published in 1976 

[ 3 ], 

The Army/Navy Computer Family Architecture (CFA) 
Selection Committee's final report recommends the use of the 
PDP-11, IEii S/370 or Interdata 8/32, based on architectural 
suitability, support software availability and life cycle 
costs. This final report recommended tc beth the Army and 
the Navy a suitable family of computers to implement 
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tactical systems. Tbe committee did net consider LSI 
computers, possibly because some of these computers had nor 
teen announced at the time the committee started its work. 
However, the committee's recommendations are largely based 
cn the availability of support software for these systems 
whicn are architecturally acceptable. The existing Navy 
standard computers, AN/UXK-7 and AN/UIK-20 failed to qualify 
architecturally under the criteria used by the committee, 
and would be pcor choices because the support software base, 
even at this point in time, is inadequate. The committee 
did not anticipate the impact that LSI computers have had on 
the cost of support software. The committee did not 
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that 
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development would 
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r the application 
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is 



general agreement that program development is best dene on 
special developmental systems, as is the case with many LSI 
computers. 

E. A METHOD FOR ESTIMATING VSTOL'S NEEDS 

Before we can realistically compare alternative system's 
i mplementaticns, we must estimate program size, execution 
speed requirements, and data flow requirements. We 
introduce methodology based cn graph theory, which permits a 
detailed analysis of execution speeds and data flows. We 
apply these techniques to analyse the A6-E operational 
flight pregram. 

If the execution speeds for the instructions of a 
particular computer are known, then we can estimate 
accurately the execution times that a program segment would 
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require if executed on that computer. Similarly, if we know 
the data bus data transfer speeds, we can accurately 
estimate the time required to transfer data between 
computers. Based on this analysis, we can accurately 
estimate the number of processors needed to carry out the 
A6-E operational flight program using a homogeneous 
distributed system or a heterogeneous distributed system. 

Because system's needs for VSTOL are similar to fixed 
wing aircraft which carry out the same functions, we can use 
the A6-E tactical program as a starting point for 
extrapolating the operational program requirements for 
VSTOL, attack version. Similarly, the S3-A can be used as a 
starting point for estimating the system's requirements for 
VSTOL used as an antisubmarine aircraft. 

Ey establishing feasibility of homogeneous distributed 
systems with presently available commercial LSI processors, 
it is clear that the improved capability of the LSI 
computers by 1980's will reduce the number of processors 
required and also reduce the presently experienced hardware 
costs . 



C. ORGANIZATION OF THE REPOET 



Chapter III describes the so-called LSI revolution, its 
implication both in hardware and software development. Tne 
industry trends in process control applications and embedded 
ccmputing are discussed and related to the future of Navy 
airborne tactical computing. 

Chapter IV states the problems posed by rapidly changing 
technology. Design principles applicable to airborne 
tactical system's software and hardware design are stated. 
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Ihe two major design alternatives: homogeneous and 

heterogeneous are discussed in detail. 



The methodology for the analysis of distributed s 
is given in Chapter V. Execution time analysis tech 
and data flcvi analysis are both based on the conce 
graphs. From this analysis execution times c 
estimated, data flow requirements between proc 
elements can be determined and partitioning strategy 
formulated. 

Chapter VI applies the analysis methodology to th 
system. A detailed association of computational steps 
program segments is obtained from the A6-E opera 
flight program documents. Data flow requirements fc 
suggested program partition elements is calculate 
program size estimates are given in both higher 
languages and a machine language. Estimates of the 
operational flight program are obtained. 
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natives are considered 
s distributed system's 
processors is compared 
implementations with 
ill allow more capable 
weight and at less 



Comparisons in the reliability of the designs are 
considered in Chapter VIII. Economic analysis with two 
scenarios for future possibilities are considered in Chapter 
IX. 
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III. IMPLICA TION S OF LA RGS SCALE INT EGRATI ON 



A. TECHNOLOGICAL CHANGE AND LSI IMPLICATIONS 



The technology of large Scale Integration is one of the 
most significant technological events in the twentieth 
century. A machine can now te endowed with "intelligence". 
Although computers have been in existence for more than 
thirty years, cnly very special machines could afford 
"intelligence". For example, the Mars lander was one such 
machine. In the near future many machines will have 
capabilities of the Mars lander. 

The agriculture industry’s tractor which converts 
chemical energy into mechanical work has made it possible 
for two percent of the population in the United States to 
feed net only the entire population of United States but 
millions of ethers. At the turn of the century sixty 
percent cf the population was required to feed the rest. 
Similarly, with "smart" machines, the productivity cf each 
of us can increase to such an extent that cnly a minority of 
workers are required in the direct production of the world's 
goods, the rest could te employed in services or information 
processing. Radical changes will taxe place in tett tne 
social structure and our values as a consequence cf a 
silicon chip which can be made into a willing slave, a 
skilled pilct, or a deadly weapon. 

The technology of Large Scale Integration affects 
military airborne systems in three major ways: 
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1) Ihe cost of the hardware is potentially radically 
reduced. 



2) The system’s weight and power requirements are 
radically reduced. 

3) The system's design distributes the computing among 
several computers. Distributed system's architecture allows 
future add-ons zo be made in an orderly way. 

In order to gain insight into why the radical cost 
reductions in hardware are possible, we start with cost 
analysis for LSI technology. 

In producing any product, the cost can be divided into a 
nonrecurring cost, NBC, and a recurring cost per unit item, 
ECU. If we produce N items of a certain type, then the 
sales price per unit, SU, should be such that the income on 
the left cf the inequality exceeds 

N*SU > N*RCU + NEC 



production cost on the right. In general, the quantities in 
this formula are time dependent, sc that each should be 
expressed more accurately as N(t), SU (t) , ECU (t) , NEC (t) . 
In order fcr the producer to continue successful operation 
in the long run, at seme point in time 




o 



(t) *SU (t) dt 



y 



> \N (t) *RCU (t) dt +\NEC(t)dt 



It depends on th 
the inequality 
in the long run. 
sales price, the 



e company's pricing policy whether 
holds at several points in time or 
Fcr companies which do net chang 
above formula simplifies to 
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SU > RCU + NRC/N (t) 



lo frame the cost issues in LSI technology ty this 
inequality, first note that the microelec trcnics issue of 
the Scientific American [21] breaks down the manufacturer's 
recurring cost of producing the LSI chip as fellows. 

Ccst Component Cost/Chip Cum Ccst/Chip 

Untested chip $0.10 $0.10 

cn a wafer 

Iested chip $1.00 $1.10 

assuming 20% yield 

Eackaging and package $0.50 $1.60 

testing a chip 

Assembling chips $1.00 $2.60 

cn a circuit board 
100 circuits/board 

Cabinet and power $0.35 $2.95 

supply fer a 20 
board system 



Ihe ncnrecurring costs are measured into the millions of 
dollars. These costs include: the cost of market surveys to 
decide what to make, the logical design, the layout design, 
the documentation for the design, design of tests for each 
chip, the writing of users manuals, advertizing and 
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disseminating information about the product, life testing, 
user education etc. An estimate for the nonrecurring costs 
associated with the very successful INTEL 8080 chip is 
15,000,000. 

The 8080 chip sells from several distributors at $15 per 
chip in single quantities. Putting the numbers into the cost 
formula 



shows that sales of the number of 8080 chips to date has 
totalled at least about half million. Later in this report 
a sales estimate of about 6 * 10 6 micr cprocessor devices for 
the industry is made. Kith INTEL holding abcut 30 % of the 
market, that would be roughly 1.6 * 10 6 devices or a total 
cost per chip of $5. 

It is very important to understand that Large Scale 
Integration by itself will net reduce the cost of computer 
hardware. It is only when a chip or a system becomes 
popular that the sales price drops to recurring production 
ecsts. As an example, the AN/UYK-14 is built frem LSI 
chips. The total estimated production cost for the chips 
is: 



$15 > $1.6 + $5 * 10 6 /N (t) 



Memory 65K x 1 6 
CEU 

I/O channels 

Miscellaneous 

Tctal 



= 65 chips, 16K bits each 



= 14 chips 
= 32 chips 
= 20 chips 
=131 chips 
x $3.00 



Estimated recurring 
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production cost 



$393 



fchile it is true that military specifications require 
different packaging and additional testing of the chips, 
which causes a cost escalation by a factor cf 2 - 3 per 
chip, the estimated recurring production ccsts would still 
range freon $300 - $1200 per system. 

The present aguisition cost of the AN/UYK-14 is 
approximately $50,0C0. There is no reason to suspect 
excessive profits simply because the nonrecurring design, 
test, documentation and customer education ccsts are high 
and the potential sales volume is relatively low. Hence 
even with a contract strategy which separates development 
from production phases, as with the AN/UYK-14, the 
contractor is still prcoably amortizing development costs in 
the production phase of the contract. 

In order to make effective use of the LSI technology, it 
is important to select a system which is widely used. The 
ncnrecurring production costs can then be shared ameng a 
large population cf users. 

A massive use of a system has also important 
implications in software costs. The same ccst formula can 
be applied tc software production. 



SU > RCU ♦ NRC/N (t) 

The ncnrecurring cost is estimated to be in the range 35 
$80 per instruction. The recurring cost usually involves 
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duplicating a magnetic tape, a paper tape, a floppy disk, or 
a deck or cards. In all cases the recurring cost is almost 
negligible. Therefore, the aguisirion cost of a program 
which has a large number of users becomes small. For 
example, a floppy disk operating system, including utility 
programs such as assemblers, editors, debuggers, compilers, 
for an INTEL 8080 system sells for $75 per copy. The length 
of the program is about 30,000 instructions. Therefore the 
aguisiticn cost per instruction is $.0025. Typical sales 
prices for FORTRAN, BASIC, COBOL compilers range between 
$500 - $1000 per compiler. This contrasts with the Navy's 
estimated aquisition cost [3] of $4,900,000 for the CMS-2 
language compiler. Even if there are 100 Navy program 
development centers using this compiler, the cost to the 
user is $49,000. 

£. INDUSTRY TRENDS IN EMBEDDED COMPUTING 



Microprocessors are architecturally designed to permit 
maximal use cf the chip area. The continuing trend is to 
place mere and more circuits on a chip. The trend is in 
three directions: 



1) 



The microcomputer on the chip 



(INTEL 8048, TI-S940) . 



2) Greater 
(TI-9900) i.e. 
chip . 



arithmetic capability on the CPU chip 
16 bit multiply and divide function cn one 



3) Byte slice 
cf arbitrary word 



chips which can be used 
length (INTEL 3000, AMD 



tc build computers 
2900) . 



A few 
board which 



years ago the microcomputer system 
had the CPU with additional chips to 



contained a 
communicate 



34 



with memory and input /output. The memory and input/cutput 
ports were on separate boards. The single board computers 
combine the CPU, memory, and input/output circuits cn one 
board. The latest trend is to put the CPU, memory and 
input/output circuits cn a single chip. 

Undoubtedly the most useful chip will be the one which 
is arithmetically powerful, contains a sufficient amount of 
memory which can be extended and has input/cutput 
capability. 



C. THE FUTUEE OF NAVY AVIONICS 

If the single chip computer of the 1980's will have 
8K-16K bytes of memory, it will be powerful enough to 
perform each of the modular functions which are currently 
implemented in airborne tactical systems. 

The leading micr cccmputer manufacturers have developed 
parallel time multiplexed bus technology (INTEL-MU1TIEUS, 
EEC UNIBUS, II TILINE). The hardware bus technology is 
supported by distributed single board real time executive 
software so that the user need not involve himself with 
anything but applications programming. 

3y the first half of the 1980's powerful distributed 
systems consisting cf a network of single-chip computers on 
cne board will be replacing the present single board 
computers. 

Auxiliary memory in the form of magnetic bubbles and 
charge ccupled devices will provide essentially unlimited 
auxiliary memory for these applications where auxiliary 
memory provides memory space for occasionally used procrams. 
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Ihe presently limited human capability of writing programs 
will be the only delay in the process cf creating useful 
systems. 

The Navy has an opportunity to use this new technology 
tc its fullest. It cannot afford to dc so by continuirg to 
create its cwn special brand cf computers (AN/UYK- 1 h) and 
continue to use its own special brand cf languages (CKS-2) . 
Ihe dedicated airborne tactical systems can be designed and 
implemented by the use of distributed LSI processors. 
Chapter IV and Chapter VII shew in detail how this can be 
accomplished for the A6-E system, or systems similar in 
function, VSTOL . Cur design maices use cf the presently 
available LSI processors in erder to establish feasibility. 
Ihe more powerful LSI processors likely tc exist by 1965 
will make future system's design easier, the total systems 
weight susbstantially smaller and the computer system's 
reliability higher. 
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IV. PRO BLE M STATEMENT 



A. DESIGN PRINCIPLES 



1 • Introdu ction 

This section discusses some principles for the 
design of large, special purpose computer systems such as 
occur on aeroplanes, ships, and ether large, complex systems 
involving information gathering, transformation, and 
transmission . 



First, the words "large" and "system" imply a 
systems design approach, which in turn means that we ask, 
"What must we do?" rather than the usual, "What can we do?" 
Of course in the end we must be able to carry cut the 
design, hut understanding the systems constraints should 
precede putting something together to see if it "works". 

Second, we have learned from past experience that 
testing is a major problem in computing systems. Why is 
testing sc hard? At the bottom is the simple fact that the 
growth of the number of combinations of the various parts of 
a typical computer system (both hardware and software) is 
astronomical; it is totally impractical to try every 
combination to see if it works. For example, a million 
computers working for a million years at a million times 
current speed (a million operations per second) can dc less 
than one millionth of the possible 64 bit by 64 bit 
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multiplications. Thus we cannot ncpe tc test the entire 
complex system as a whole, we can only verify that for an 
infinitesimal fraction of special situations the system 
works, and then hope that the rest is correct. Therefore, 
we must actively seek designs that make it possible tc test 
the parts separately, and then test the interconnections at 
the interfaces one by one at most. 



As a practical example of this combinatorial 
principle, consider the fact that it is easier to des 
integrated circuit than it is to design the tests fo 
that it is easier to manufacture an integrated circui 
it is tc test it afterwards to see if it operates pro 
that it is easier to build software and other program 
it is tc test them. 
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As an example of two different approaches to the 
design of a software package consider the problem of writing 
a program tc integrate a particular second crder non-'linear 
ordinary differential equation. If you Degin by writing a 
general purpose integration routine, then you can test it 
using various standard functions like sines and cosines, 
growing and decaying exponentials, Eessel functions, etc. 
*iith a wide variety of well known functions ycu can prcbably 
cover most of the particular aspects of the equation ycu 
have to solve. Finally by specializing the general purpose 
routine tc the particular problem , you will have a great 
deal more ccnfidence, at a lot less labor, than witfc the 
direct approach to the special case. Of course the general 
program may well oe slower and use more storage than the 
optimal, special purpose routine, but by gcing the general 
purpose path you have gained a lot in both reliability and 
savings in the effort in testing. 



in 



The same applies to hardware. It has been observed 
the literature that it is easier to test a computer with 
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a "random access storage" device than it is cne with a "read 
only storage" device. In the latter case ycu must provide 
extensive testing equipment outside the computer to dc the 
testing; in the general purpose case you can use the device 
itself to aid in much cf the testing. 

From these examples we extract three principles; 

1. We must deliberately seek designs that make the 
testing# fccth of hardware and software, as easy as possible; 
not only initially but over the life of the system with its 
many changes and upgrades. 

2. General purpose hardware and software offers 
flexibility at the testing stages, and furthermore it tends 
to be composed of relatively independent parts. Therefore 
at every stage the general purpose system should be 
considered instead of special purpose tricks that appear to 
save money and effort at the moment. 

3. A homogeneous system, both hardware and 
software, tends to be easier to test, both in the designing 
cf the tests and their execution. Furthermore, there is a 
great degree of self-testing of the homogeneous structure as 
it is used in the various ways in the whole system. ftny 
errors that are found and removed are thereby removed from 
all their appearances at the same time - they need net be 
feund again and again if the correcting is done to the 
system, net to the detail where it is first found. 

Eut it is obvious that the prcnlem to be solved by 
the whole computer system is highly varied. Therefore the 
underlying problem is to confine this variability as much as 
possible, and to construct as regular a system as possible 
sc that the regular system may be tested relatively 
independently of the particular details of the system we 
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race 



If it is still doubted that testing is the problem, 
then consider the endless number of field changes that will 
cccur during the life cf the system. The cost of these 
changes, and the risks of errors, will greatly exceed the 
cost of the initial construction if the classical methods of 
computer system design are used. In cur judgement the 
solution to the problem of designing a computer system lies 
along the lines indicated - regular, systematic, general 
purpose systems so that the testing problem can be 
adeguately handled. Once the general system is tested, then 
the special cases cf the particular problem can be used with 
fair confidence. The cost is that somewhat more capacity in 
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percents, but is nowhere near double the minimal capacity. 



2 • Generalized Testi ng 



It comes as a surprise tc many 
be general purpose testing methods 
independent cf what is being tested 
this is the testing of the computed an 
equally spaced function evaluations, 
will be close enough fcr the function 
the usual method of constructing a d 
function can be used tc reveal isolate 
in flight, streams cf smooth data 
smoothness, and isolated errors locate 
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. A simple example of 
swers cf a sequence of 
Typically this spacing 
to be "smooth". Thus 
ifference table cf the 
d errors. Similarly, 
can be checked for 
d as they occur. 



Another example of generalized testing is as 
fellows. Given a double precision routine fcr integrating 
ordinary differential equations (in practice this should 
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one can 



include the ability to handle given singularities) 
test library programs of special functions by supplying 
their differential equations and starting values, and then 
comparing tbe results at a tight net of points. One gets 
tens of thousands of checks without any human ever being 
tethered with providing the check data. The same tool works 
on most special functions, and once tested or a couple of 
functions it is probably well debugged. The general purpose 
tester, by its generality, gets debugged early, so that 
apparent errors that later appear are most likely due to the 
program tested not the test program (which in the past has 
been one of the curses of testing) . The errors in the tester 
are much more likely to be discovered from its multiple use 
than are these of special purpose testers. 



As a final example of general purpose testing 
can test a data transmission system by encoding a 
input message into an error detecting and/or an 
correcting system, and at the receiving end isolated 
can be detected without knowing what that input was 
course if the same random number generator were 
receiving end, a more complete check could be obtained 
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random 
error 
errors 
Of 

at the 



Ihis, then, is one of the things we seek; general 
purpose methods of testing that can be automated in the 
sense that humans do not have to construct the correct 
answers to be used in the testing. Human capacity is too 
limited to do much this way. Such a general purpose tester 
can supplement the comparatively few tests that humans can 
devise and apply to the whole system. We need an ensemble of 
tests that do not require human thinking to apply to each 
one , sc that from the outputs alone the machine itself can 
locate many (not all) errors. Thus the computing capacity of 
the system can be used to test itself without exhausting the 
human invention of special tests and the efforts necessary 
to apply them. 
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If the same kinds of general purpose chips are used 
throughout the system, then the testing is much reduced; 
alternati vel y , given the same amount of testing resources, a 
few types of chips can be more completely tested than can a 
wide variety of chips. 
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chips so that when the time occurs for the final desicn co 
te made from the integrated circuits, the basis for good 
design will be known. If the testing is started shortly 
before the final design must be made, then the life testing 
will have toe short a time to be meaningful. 



4 . Eel iaple Compu ting from Unrel iable farts 



Ihis is not a new field. Error detecting and error 
correcting codes have been knewn and used for many years. 
Ihe codes in the literature have been designed mainly for 
'•white noise". Special situations and particular failure 
modes require other inventions, but the field is 
sufficiently well known so that invention is not hard to do. 
fer example, suppose you decide to use read only storage 
devices fer all pregrams, but that occasionally such storage 
devices fail completely. How does one construct a 
reasonable way for recovering without duplicating all of 
storage? One way is tc put an error correcting code on each 
storage chip, and this will allow isolated errors tc be 
corrected. Ihese error correcting codes can have their bits 
in location 000... and the top end of the chip witheut much 
trouble, so that the checking bits are not scattered all 
ever the stcrage device. If a larger failure occurs, say a 
whole bank goes out, or the error rate rises sharply 
indicating a disaster in the near offering, then we can do 
the following. We carry a spare storage device which has 
the logical sum of all the other storage units, except the 
failing cne, into the selected spare, we can reconstruct the 
failing cne (without reading it at all) . Any isolated errors 
in it can be corrected by its own error correcting code. It 
is not being claimed, in the absence of any reliable data, 
that this shculd be done - it is given only as an example of 
hew one can compensate for unreliable parts without the 
heavy ccst of duplicating every part, or even triple or 
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"guadding" each part. The more parts you put into the total 
system tne mere failure you will have and the less you will 
be able to test the individual parts (since it is supposed 
that you have a fixed, finite amount of effort to do this). 
Mere intensive checking on fewer parts is tetter that less 
intensive checking on more parts. 



5. Testing Software 

Just as using the same kinds cf parts in the 
hardware greatly eases the problem of testing, so toe will 
the use of the same kinds of software. Care snould be taken 
that the same functions are not programmed in trivially 
different ways in different parts of the network of 
computers. The software should be approached as a whole - 
systems design is necessary in software. 

Since the software must do different things, it 
fcllcws that there must be differences. How, then can we 
get homogeneity in it? One method is to start with the 
mathematical equations in a standard notation (say FOETEAN) 
along with the corresponding Boolean logical realionships 
and the timing conditions. Then using appropriate general 
purpose compilers (say FORTRAN plus a separate timing 
checker) we can get the code we need generated by the 
machine itself. 



If an error occurs, there will be a great tendency 
for the programmers (judging by past experience) to "patch 
in machine cede". This should be resisted as much as 
possible. Instead, gc back and fix the cause, the original 
statements, the bug in the compiler, or whatever it turns 
cut to be, hut do not fix the isolated error as an isolated 
error. The object should be to get all the final code to be 
machine generated in a uniform fashion by as simply 
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constructed compilers a possible. Thus by testing tne 
general purpose compilers on many problems where the answers 
are easily known and checked, the compilers can be 
thoroughly tested. Then (as in the earlier cited 
differential equation example) the special cases that arise 
in practice will be more surely compiled correctly, 
furthermore, all the inevitable changes that arise in the 
course of the life of the aeroplane will use the same well 
tested compilers, rather than going through the hands cf new 
programmers who will have forgotten, if they ever knew, why 
things were as they were. 

While we believe that much more can be dene to 
create homogeneous software, the appropriate theory is not 
yet available, so the above is the best we can recommend at 
tnis time. 

An example of getting fairly homogeneous software is 
the idea cf having a table of status values and a program 
that uses the table to decide what to do next. Thus all the 
priorities are easily located and isolated for close 
inspection and control. The table values can be easily 
changed in mid flight, but the formula of evaluation should 
be changed only after long, careful study cn the ground. 



6 . Reliable So ft ware f rom Unreli able Rrc gramme rs 



The same problems of reliability occur in software 
as occur in hardware, though perhaps a bit more severely. 
The answer we have given above, use the system to generate 
the software rather than let unreliable humans touch the 
final version, seems to be the best protection against the 
all too common isolated, foolish errors. 

More needs to be done along these lines, but studies 
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of the kinds of software errors that occur are too few and 
tco scattered to be very useful at this time. By the time 
software is to be built, much more will have been discovered 
cn how errors arise. But the principle that the machine 
should write the final code will still apply. 



Fault tola 
has received exte 
should net be i 
moderately carefu 
principles in all 
many good remarks, 
not be ignored, 
much. 



rant computing, both software and hardare, 
nsive attention in the literature and 
gnored. Eut so far as we can see from 
1 study, there are nc fundamental 
that has been written. Instead, there are 
observations, and suggestions that should 
but neither should it be depended upon too 
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Even if the hardware runs correctly and the software 
en to specifications, there is still the chance that 
en eguations. Boolean statements, and timing 
ns are wrong. Thus there must be testing of them 
well as the whole system. First, many of the 
s that are to be used cannot be completely new; much 
ate rial must have been used in similar situations, 
se should be used whenever possible to compare with 
being proposed. 
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much as has 
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constructed 
to generate 
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should be se 



nd, it is possible to design systems simulators, 
teen already done for some parts of the problem, 
test the system behavior as a whole before it is 
in hardware and software, and can also he used 
check tests on the complete target system, 
ems simulators of varying degrees of detail 
riously considered. 
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Tnird, it is possible to build test equipment to 
simulate reality so that the assembled system has pseudo 
real signals as inputs. For example, a simulated target can 
be rolled across a hangar floor to see that the numbers at 
various places in the computer system are very close tc the 
theoretical cnes. Much as it seems tc be trivial, the 
testing cf the original proposed system is necessary. As 
experience has shown, errors can creep in at this early 
stage, let alone at later stages when small (apparently) 
changes in the terminal sensors and effectors are made. 
Each such change requires a careful examination to see if 
the changes are consistent with ether assumptions. 

8 . Summary 

History has shown that the past habit of "letting 
testing occur in its natural place" is very expensive . The 
combinatorial complexity of computers, beth hardware and 
software, makes complete testing of current systems 
impossible. 

A few people have finally realized that design 
begins with testing (acceptance tests if you wish) . Cc not 
design what you will net be able to test carefully. 

Generally, small, standard, flexible units are more 
easily tested then are specially designed cnes. Through 
use, isolated errors that escape the initial tests are 
caught. Cnee caught the error is to be removed, net by 
patching, but by careful analysis of hew it escaped the 
testing, and then the cause is removed. 

General purpose testing (both initially and in 
flight) is an area that offers great returns from limited 
human effort, and should be pursued further. 
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TWO ALTERNATIVES: EOM OGENEOUS OH HETEROGENEOUS 



1 • distributed De dica t ed C omputing 



The term distributed computing is a broad term which 
has a widely different meaning to different people. An 
attempt to define the term "sharply" leads to disagreement 
and sometimes even emotional outbursts simply because my 
definition is right and yours cannot possibly have any 



merit . 



In the context of this report, distributed computing 
is used in the broad sense which includes systems which are 
at one end of the spectrum completely uncoupled and at the 
ether end of the spectrum very tightly coupled, such as 
multiprocessor systems which share some memory. In short, 
distributed computing refers to a computing process which 
separates a task intc two or more individual tasks carried 
cun by two or more processors. 

In the case of the Navy airborne tactical systems, 
the A6-E the A7-E-D, the P-3C would not be distributed 
systems, whereas S-2C, S-3A and F-14, E-18 would be 
distributed systems. 



s y stems 
f ederat e 
cne com 
subservi 
physical 



Some of the terms frequently used to refer tc such 
are federated or dispersed systems. The term 
d connotates a certain structural hierarchy so that 
puter acts as the executive and others are 
ent computers. The term dispersed connotates 
dispersal or distance between the processing 
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elements. In our use of the term distributed, no 
connotations of this type are implied. If we wish to 

discuss physically dispersed processing concepts, we wculd 
refer to such distributed systems as physically dispersed 
distributed systems. In our use of the term, distributed 
processing dees not imply that the processing elements are 
in any sense coequal and homogeneous in structure. We wculd 
call such systems physically homogeneous distributed 
systems. Physically homogeneous distributed systems can be 
eganized intc logically hierarchical distributed systems 
where one processing unit may assume the role cf the 
executive and the others as subordinates, closely modeling 
the military hierarchy. Systems which contain 

ncnhomogenecus processors are called heterogeneous. 

The following binary tree summarizes our 
nomenclature and taxonemy. 

Digital Computing Systems 

I. Ncndistributed 

II. Distributed 

A. Heterogeneous 

1) Logically hierarchical 

2) Logically cf egual rank 

E. Homogeneous 

1) Logically hierarchical 

2) Logically cf egual rank 

Each of the categories can be either physically 
close or dispersed. 

A dedicated computing system is one in which the 
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same sex of tasks is executed over and ever again. The 
contrasting situation occurs at university computing centers 
where a task stream is constantly changing and where the 
same program is seldom executed more than cnce. 



2. Current Tre nd s In Air bc rne Tacti cal S yst ems 

The F-15 and F-1S show a trend away from the single 
central processor systems. Distributed systems in one form 
cr another is the apparent trend. Also, these systems are 
heterogeneous in that several types of computers are used. 

There is a natural force toward heterogeneous 
systems because the airborne systems manufacturers, who act 
as the majer contractor usually hire subcontractors for 
subystems: radar, electronic warfare, communications etc. 

Each of these subcontractors probably has a different LSI 
computer which they prefer to use. To force them to 
redesign a system using a different computer would naturally 
increase the contract cost. Optimization cf the contract 
cost tends tc encourage processor diversity. 

From the point of view of life cycle costs, 

diversity of computers creates substantial additional costs, 
namely 

1) Stocking line removable units for each type of 
computer at the repair station. 

2) Documentation for each distinct unit must exist 
at repair stations. 

3) A service person must either go to several 
different schools in order to learn to service different 
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systems cr different service personnel fcr each distinct 
computer type is needed. 

4) Software upkeep costs for the diverse systems 
will alsc become higher again because of dccumentaticn and 
personnel education costs. 

Our cost analysis will show the penalties the Navy 
has to pay eventually if the objective of the project is to 
minimize the acquisition costs of the systems only. 



3 • £en ef its Of Hom ogene ous S ystem s 

The most important benefit of homogenous systems is 
that human beings who are designing, servicing and using 
such systems need tc only learn one system. The human 
effort tc design, service and use computers is definitely 
the most costly item in any system. Many chips of computer 
hardware can be bought for the daily wage cf a hardware or 
software service engineer. Concern for minimizing computer 
memory by clever programming techniques is cnly economical 
when a large numcer of identical systems are designed. To 
try to isolate a hardware problem to anything other than the 
computer itself is scon becoming obsolete. How many of us 
bring a hand held calculator to a serviceman to fix it? 
Eecause a new calculator costs $20, no technician can affort 
to spend more than half an hour to service it. 

Proliferation of LSI computers at this point in 
history is unavoidable. Any new revolutionary development 
will attract many groups whc are trying to share in the 
profits and who cannot afford to spend time worrying about 
standards. Being first, establishing a reputation and 
staying first is more important and more effective in 
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establishing standards than spending endless 


hours tryin 


g to 


reach a compromise. 


It is however 


alrea 


dy clear 


that 


proliferation of 


microcomputers 


is 


ending. 


Many 


manufacturers find that they are too 


late 


or offer 


too 


little, and many have already closed 


their 


doors, or 


sold 


cut, or merged with 
teeing established. 


ethers. The de 


facto 


standards 


are 


Although the 


proliferation of LSI ecu 


puters ere 


ates 


a tendency to have 


heterogeneous sy 


stems 


the homogeneous 



systems have substantial benefits. Tc add onto a 
homogeneous system requires typically adding another board 
into an empty slot. Tc isolate problems can be dene more 
easily because swapping identically functioning replaceable 
units is a very simple and widely used technique for 
troubleshcoting. 



It is not hard to convince oneself 



systems 


have 


many advanta 


ges over heterog 


question 


is. 


how can one 


push 


ef f ecti v 


natural 


trend 


of unique d 


evices 


which has 


avionics 


industry. 







that homogeneous 
eneous ones. The 
ely against the 
developed in the 



A sclution is to encourage two trends which are 
developing naturally among LSI computer manufacturers. One 
trend is the mutual agreement by several companies to 
manufacture the same product. The 8080 is manufactured by 
several companies including Texas Instruments and INTEL. 
The ether trend is toward single board plug to plug 
ccrabatibility . The SBC9900 and the SBC808C/10/20 are plug 
tc plug compatible even though they are manufactured by 
different companies. If the Navy chose its standards to 
include the "defacto" industry standards, then homogeneous 
systems could become an economic reality in the Navy 
avionics computing. 
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V. 



MJIHODOLOGY FOE ANALYSIS OF DISIBIEUTED SYSTEMS 



A. FLOWGEAPHS 



1 • Introd uction 

Complexity cf programs has received considerable attention 
from the theoretical point cf view. Ihe complexity measure 
used is normally the number cf basic operations required to 
compute the result. 

Another significant measure of program complexity, 
namely the complexity of program control, has just recently 
received some attention [17], 

In this report both measures cf complexity, the 
executicr time required to compute the result, and pregram 
control complexity are viewed as two aspects of the same 
problem. Ey the use of graph theory, the discrete systems 
analysis problems arising in electrical engineering or 
hydraulics engineering are shown to be abstractly the same 
as those arising in computer programming. The flowgraph 
which is used to describe computer programs is somewhat 
different from the traditional control graph. The view of 
flowgraphs presented here also corresponds tc network flow 
problems for which there is a unit cost associated with 
flows through an arc. In Section A. 2 the abstract 
similarity of Discrete Systems Analysis and computer 
programs is pointed out. In Section A. 3 Kirchhoff's Laws 
are applied tc derive basic relationships which describe the 
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are 



behavior or the discrete systems. These relationships 
dependent cn the structure of the system only ar.d are 
applicable to all discrete systems which can be 

characterized by a dual set of variables called the flew and 
potential variables respectively. Section A. 4 shows hew the 
techniques used to solve discrete systems problems are 
equally applicable to determine execution time values in 
program segments. Section A. 5 derives an expression fer the 
total execution time in terms of independent flow 
parameters. A summary is presented in Section A. 6. 



2 • Abstract Similarity of D iscr ete Sy stems 



In this 


section w 


e introduce a v 


which shews the 


abstract 


similarity of 


problem to the 


problems 


in engineerin 


analysis. Fcr a 


complete 


treatment of 



arising in engineering, [12] and [16] are 
Eeference £7] treats the problems in netwo 



iew of programming 
the programming 
g and operations 
discrete systems 
excellent sources, 
rk flows. 



figure V.A.1 illustrates three discrete systems 
arising frem electrical engineering, hydraulics and computer 
programming . 



We view the three discrete sytems as a collection of 
two terminal elements such as batteries, resistors, current 
generators, or pumps, constrictions in pipes and flow 
generators, or sequences of computer program statements, 
control statements and start and termination statements. 
The way in which the two terminal elements are joined 
together gives rise to a connected system cf two terminal 
elements which may be described by the graph in Figure 
V.A.2. 
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(b) 







1 



2 



5 



(c) 




FigureV.'A t i THEEE DISCRETE SYSTEMS 
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igursV.A.2 ABSIMCTICN 0? THREE DISCRETE SYSTEMS 
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In 

terminal cf 
terminal cf 
resistor fi 

1 



figure V. A. 1(a) the vertex represents the 

resistor R which is joined tc the positive 

1 

the batterv. Arc a represents the two terminal 

1 

The remaining correspondences are 



a :R,a : R , a : I (t) , a : R , a : V (t) 
22334 556 

where I(t) represents the current generating element 
and V (t) represents the voltage source. 

In an analogous way the symbol X represents a pump 
whose one terminal is at a hicher pressure than the ether 

and is connected tc the constriction C . Therefore, the 

1 

arcs again represent corresponding two terminal hydraulic 
elements . 



a *C,a . 0 , 
112 2 



a 

3 




r 



a : F (t) , a : C , a : P (t) 
4 5 5 6 



The 

flowcharts 
functional 
arcs. If, 
statements 
the program 
the concept 
Figure V.A.2 



traditional way of representing pregram 

fcy a directed graph has been to associate 

statements with vertices and control paths with 

cn the other hand, seguences of functional 

are associated with arcs, and control pcirts in 

ere associated with vertices, then we may define 

of a flowgraph which coincides with the cne in 

. The arcs a correspond to the seguences of 
i 



statements: 
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a : SUM=0; 1=1; 

1 

a : SU K=S UM + I**3 ; I<5; 

2 

a _ : I<5 is TRUE; 1 = 1 + 1; 



a ; I<5 is FALSE; PRINT SUM; 
5 



a ; NO OPERATION; 
4 



a 

6 



END-START SEQUENCE; 



From the knowledge of the characteristics of the two 
terminal elements and from the way in which these elements 
are connected, we can determine the behavior cf the system. 



There are- two complementary variables x(t) anc y (t) 
which may be regarded as functions of time and which play a 
central rcle in discrete systems theory. In electrical 
engineering x (t) represents voltage differences and y (t) 
represents currents. The two terminal element, resistor R , 

is characterized by the relation; 



x <t) =R y (t) 

If the resistance value R is known and if the 

1 

current through the element is y (t) then the potential 

1 

difference across the element will be x^(t) . Eacn of the 
six two terminal circuit elements are characterized by a 
relationship cf this type 
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X (t) = R y (t), X (t) = R y (t), 

2 2 2 3 3 3 



x 

5 



(t) = R y (t) 



Voltage and current sources are specified by 
relations 



x <t) = V ( t) , y (t) = I (t) 
o 4 

We should note here that inductive and capacitative 
elements were omitted from the examples for simplicity. a 
capacitative element would have the characteristic 
relationship 

C d/dt x(t) = y(t) 

The inductive element would be characterized by 

I d/dt y (t ) = x (t) 

A knowledge of the characteristics of the two 
terminal elements and knowledge of hew they are 
interconnected allows us to formulate a linear system of 
eguations. If the system contains two terminal elements 
which have a differential relationship, then the system is a 
linear system of differential equations. In programming 
applications the two terminal elements are equivalent to 
resistors and hence only ordinary linear systems arise. In 
the hydraulics system described in Figure V.A.I(t) the 
variable x corresponds to pressure and the variable y 
corresponds to flow. Depending on the characteristics of 
the constriction, we may formulate the relations 
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a : x = C y , a :x = C y , 
1 1 1 1 2 2 2 2 



a :x = C y , a :x = C y , 
3 3 335 5 55 



a : x = P (t) , a : y = F (t) 
6 6 4 4 



In computer programs, each sequence cf instructions 

reguires a certain amount of time to execute. Therefcre we 

may associate the execution time I with each execution 

i 

sequence. Ihe variable y may be thought cf as the number 

i 

of times the execution sequence is executed, or it may 

represent the relative frequency or probability with which a 
particular execution sequence is executed. Ihe total time 
that a program is in the given execution sequence therefore 
is expressed as 



x = T y 
i i i 



Here T is analogous to resistance, y is analogous 
i i 

to current flow, and time consumed by the pregram segment is 

analogous to the potential difference. In cur example in 
figure V . A. 1 (c) 



a :x = I y , a :x = T y, 
1 1 1 1 2 2 2 2 



a : x = I y , a 
3 3 3 3 5 



x = T y , 
5 5 5 



a :x = 1 y , a :x = T y 
4 4 4 4 6 6 6 6 
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We note here that any directed cycle in the program 

corresponds to a current generator in electrical 

engineering. We must know something about such cycles in 

order tc analyze programs. In this instance we can 

determine, looking at the program, that y is executed four 

4 

times. If we are interested in determining the total 

execution time for executing the program once, then 

6 

y = 1 and y = 4, El T y 

6 4 i=1 i i 

We note that if we think of T as a per unit cost of 

i 

flow of a certain commodity, then the above formula 

represents a network flow problem with costs, where v in 

1 

Figure V.A.2 is a source vertex and v is the sink vertex 

5 

and where the flews y may be integer constrained in case we 

i 

think of y as representing the number of times a giver arc 
i 

is executed. If we think of y as execution frequencies, or 

i 

execution probabilities, then the integer constraint is 
removed. Arcs may have capacity constraints such as a data 
dependent loop which is maximally executed • n-times . 



3. Kirchoff's Laws 



In all discrete systems cf the type treated here, 
the Kirchhoff's law which states that the sum of the flows 
into a vertex is equal to the sum of the flews out of a 
vertex is applicable. This law implies that the flews y 

i 

are related and in particular that (n-1) of the variables 
may be expressed in terms of the remaining ones, where n is 
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the numner of vertices in the graph. References [12] and 
[16] develop a systematic way of expressing the sc-called 
tree variables in terms of the co-tree variables. The 
following contains a synopsis of that development. 

Definition 1. A spanning tree T of a connected 
graph G, of n vertices is a connected subgraph which 
contains all n vertices and has n-1 arcs. 

Cna spanning tree of the graph in Figure V.A.2 is 
given by the heavy arcs. Each remaining arc in the graph 
belongs to the co-tree, that is, the complementary part of 
the spanning tree. 

Definition 2. Let us consider a graph in which the 
directions of the arcs are ignored. Such a graph is called 
an undirected graph. If a co-tree edge is added to the 
spanning tree of such a graph, a unique seguence of edges, 
known as a circuit, is formed. This circuit consists cf the 
co-tree edge whose terminal vertices v , v are connected in 

i j 

the spanning tree by a subset of edges in the tree. The 

circuit consists of the sequence of edges a, a, a, a. 

6 12 5 

Each co-tree arc added to the spanning tree arcs in turn 

creates a unique circuit consisting of the cc-tree arc and 
the arcs in the spanning tree. 

The totality of circuits so formed constitutes a 
basis in the vector space of all circs. 

Definition 3. Let c = (x ,x ,...,x ) be a vector 

1 2 m 

whose components x consist of zeroes or ones and where the 

i 

index m represents the total number cf edges in the 
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undirected graph 



1 



. A vector c represents a circuit if j = 

i 

whenever a is in the circuit and x =0 whenever a is not 
i i i 

in the circuit. Such vectors form a vector space under 

componentwise modulo 2 addition. The vector space is called 
the space of circs. 



Associated with the flowgraph in Figure V.A.2, we 
have the basis circuits 




The vectcr space of circs in this case consists of the 
modulo 2 sums 

c 2 © c 2 = (101, 1 0 1, 000, 000, 101, 101) 

= ( 0 , 0 , 0 , 0 , 0 ) 



C 1 0 c 2 = (! 0 1 1 1 ) 

The total number of circs is 4 in this case, or more 
generally 

M 

where 

M = E - (V- 1) = E - V * 1 

M is called the cyclomatic number, E is the number 
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of edges in the graph and V is the number cf vertices 



The concept of c 
consider the direction of th 
direction cf the co-tree 
circuit which is fcrraed. By 

Figure V.A.2, the arcs a 



ires remains unaltered if we 

e arcs in the circuit. The 

arc induces a direction in the 

adding the co-tree arc a in 

6 

, a , a agree with the induced 
1 2 5 



direction and hence the corresponding 



vector is 



c 



2 





3 

0 



a 4 a 5 
0 1 




If a were directed frem v tc v then the induced 
6 1 5 

direction of the circuit would be opposite of arcs a , a 

5 2 

and a , hence the vector would be represented as 
1 

a l a 2 a 3 a 4 

c 2 = (-1 -1 0 0 




Although the signs are unimportant in modulo 2 
arithmetic because -1 = 1, the signs become important when 
the directicr cf flows is considered. 

The relationship between the flew variables could 
have been obtained by applying Kirchhoff's laws of flow into 
a vertex is equal to flow cut of a vertex at n-1 vertices, 
lie have chosen to express the relationship by usinc the 
concept of circs. The result provided in detail in [12] and 
[16] is as fellows. 

Theorem 1. The tree flow variables can be expressed 
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in terms cf the co-tree flow variables by usinc the 
coefficients matrix whose columns correspond to the signed 
incidence vectors representing the basis circuits. 
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where 



x. , 
lk 



0 if tree arc i is not in circuit k 

1 if tree arc i is positively incident 

in circuit k 

■1 if tree arc i is negatively incident 
in circuit k. 



In the flowgraph in Figure V.A.2 the relationship of the 
spanning tree variable is 
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he note that in the first equation above 



y = y 
1 6 



which states that the flow cut from vertex v is equal to 

1 
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Kirchhcf f ' s 



the flow into vertex v 



1 



Cne can use the second 
potentials to relate the co-tree variables 
variables. In any circuit in the network the 
potential differences is zero. 



law 
to the 
sum of 



for 

tree 

the 



Theorem 2. The co-tree potential 
expressed in terms of the tree potential 
the transpose of the matrix X in Theorem 
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4 • ^ lem F or mulation and Solu tion 



variables 

variables 

1 . 




can be 
by using 



Vie shall now formulate and solve the three 
abstractly similar problems. 



In the problem in Figure V. A. 1(a) we have the 
following relationships for each of the twc terminal circuit 
elements . 

R 1 0 0 0 

0 r 2 0 0 

0 0 r 3 0 

0 0 0 R 5 

Ey Kirchoff's laws, flow variables are related by 







/ \ 



/ 



( 1 ) 
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and the potential variables are related by 




r 5 / 



Eremultiplyirg (1) 




Using (3) on the left and (2) cn the right 




Depending on what information is prescribed, the problem can 

be easily solved. If we knew I = I (t) and v = V (t) , then 

4 6 

v and I can be determined in terms of I (t) and V (t) as 
4 6 

fellows: 
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V 4 = (R 2 + R ) I(t) + R 2 Ig 
v ( t ) = R 2 I(t) + (R x + R 2 + R 5 )I g 
V ( t ) - R 2 I(t) 



/ v ( t ) - R,I (t) \ 

V 4 (R 2 + R 3 } I(t) + R 2 + R 2 + R 5 J 

In the hydraulics problem in Figure V.A.I(t) precisely the 
same results would re obtained if the flow rate F(t) and the 
pressure difference P(t) were prescribed. 



In programming problems we typically know the flow 

values. For example, if we execute the pregram in Figure 

V. A. 1(c) once, then y = 1. Because the lccp is executed 

6 

exactly four times y =4 and hence: 

4 




Here x represents the total execution time in the interior 
4 

lccp, whereas represents the execution time in the 

exterior loop. 
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5. 1 he lotal Ex ecution T ime 



The total execution time can now he expressed in 
terms of the linearly independent flow variables. 



TOTAL TIME 
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mere generally 
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6 . 



Summary 

Ibis report shews that discrete systems analysis is 
analogous and applicable to the analysis of computer 
programs. Ihe traditional view of flcwgraphs [17] 
associates vertices with blocks of code and arcs with the 
flow of control. That view does not lead to the 
correspondence exhibited in this paper. 

i 

Vie wculd like to also point out the similarity of 
the flcwgraph analysis to the problems encountered in 
network flows in which a unit flow through the arc is 
associated with the cost [7]. 

Eecause both discrete systems analysis and network 
flew problems are highly developed areas in engineering and 
science, the tools and techniques developed in these areas 
become applicable to computer program analysis. 

Program analysis software development which 
automates the analysis of programs usinc the discrete 
systems analysis techniques described here is a task which 
we hope to encourage by this segment of the report. 



E. DATA ELCkGRAPHS 



1 • Introdu cti on 



The basic inadequacy 
both flowchart and programming 
forms concentrate on how a 



in program cccumentat icn in 
languages form is that both 
rcblem is being solved rather 
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than what th€ problem is. 

If we design a multiplier either in hardware, 
firmware cr software, it is essential tc know what the 
problem is. In proving correctness of programs we must 
first state what the problem is before we can verify that 
cur method of solving it is correct. 

There are three major ways in which we state what 
the problem is: 

(1) by the use of formulas; 

(2) by drawing boxes and joining them with lines; 

(2) by the use of decision tables. 



Formulas have the advantage that we 
manipulate them in order to derive eguival 
which serve to simplify the problems. Al 
directly and easily be communicated tc 
compilers are available. 



have leaned to 
ent expressions 
sc, formulas can 
computers if 



Formulas have disadvantages when they extend ever 
several lines or several pages, or when a large collection 
cf formulas are used to describe a problem. Computer 
designers have used both formulas and drawings to document 
the designs. IBM is a major user of drawings. resign 
documents which describe computer hardware are documented 
with box/line drawings. 



Eox/line drawings have both advantages and 
disadvanages. The major disadvantages of these documents 
are that we must relearn to manipulate the drawings in order 
to simplify them and that we have no compilers for graphics. 
Generally human transcribers are used to translate graphic 
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pictures intc notation understandable tc the computer, 
computer redraws the pictures usually losing posi 
integrity fcr both boxes and lines and thus losing 
(possibly important) information. 

The major advantages of box/line drawings are 
data flew can be explicitly shewn across for 
information is not constrained to lines (cne’-dimensi 
and levels cf abstraction are conveniently achie 
functionally labelling boxes and lines. 

This segment formalizes the concept cf the ho 
drawings. Such drawings form a bipartite directed 
bi-digraph, which we shall also call a data flowgraphs 

A pregram flowchart alsc corresponds to a 
construct called a flowgraph. Tc each execution segue 
the flowgraph corresponds a data flowgraph which des 
at a chosen level of abstraction what happens to the d 

A siailar data flow analysis is carried out by 
and Cocke [1], although both their ccntrcl flow an 
flow are differently conceived and applied. 

A control complexity analysis which makes use 
control flow graph and introduces a complexity measure 
cyclomatic cumber of the contrcl flowgraph, by McCabe 
has some similarities to our concept of the flowgraph. 
flowgraph ic the in this section is abstractly the s 
graphs used in circuit theory, discrete systems ana 
and cost criented network flew problems. 

Shneiderman et al [21] showed experimentally 
flowcharting has little value in increasing prog 
productivity. The value we see in flowcharts or flow 
is related to automated computer analysis of algor 
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toth the execution time analysis and the data flow analysis. 

In the previous segment the flowgraph corresponding 
to the flowchart was defined and shown tc be abstractly 
identical tc similar graphs encountered in discrete system's 
analysis. In Section 2 the data flowgraph corresponding to 
an execution sequence in the flowgraph is defined. Section 
3 illustrates the usefulness of the concept ly applying it 
tc the analysis of an airborne real time tactical system 
(A6-E) . Section 4 is a summary of what this segment 
contains . 



2. Eat a rlowqraphs 



Although the flowchart analys 
effective way of determining execution 
complexity of programs, it dees not give mu 
the independence of processes or hew p 
executed simultaneously without interfering 
Ihe concept of data flcwgraphs helps to gra 
what happens to data, how data is transfo 
can partition the process into subprocesses 
need of data transfers. 



is gives us an 
times and the 



cb informa 


tic 


n on 


recesses 


can 


be 


with each 


ct 


her. 


phicall y 
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hew 


one 


with a 


m in 


imal 



fce illustrate the ideas first before we formalize 

the concepts. Referring back tc Figure V. A, 1(c) and Figure 

V.A.2 consider the graph consisting of arcs a and vertices 

i 

v . Each arc of this graph corresponds tc an instruction 
i 

sequence which carries out a computation on seme input data. 
Fcr example, arc a corresponds tc a typical assembly 
language instruction sequence. 
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IDA C 



SIA SUM 
IDA 1 
SIA I 

We associate with each data item a vertex c and 

i 

with each operation another vertex o , Figure V.B.1 in a 

j 

manner used by digital circuit designers ever since 

computers were first designed and manufact tred. We connect 
the data item to the operation which uses the data item as 
an input by an arc directed into the operation vertex. The 
output data item cr items are connected to the operation by 
arcs directed away from the operation vertex. The graphs 
resulting from carrying out this association with flcwcraphs 
are graphs which contain two types of vertices, where arcs 
connect data vertices to operation vertices and where 
operation vertices in turn are only connected to data 
vertices. £uch graphs are known as bipartite directed 
graphs, cr bi-digraphs [2 ]. 
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Fig.V.B.l Two Components of the Graph Corresponding 

to the Flowgraph Arc a^. 
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for each arc in 
corresponding ti-digraph. 
such as branch or halt 
and hence do not require a 



the flowgraph we constr 
We note that control oper 
instructions do net alter an 
correspondent bi-digraph. 
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Fig.y.B.2 Components of the Data Graph. 

we next determine an execution sequence or all execution 
sequences for a given flowgraph. 

We are now ready to formalize the definition of a 
data graph. 

Definition 3.1. A data flowgraph corresponds tc an 
execution sequence in a flowgraph as follows. Let 

S — (3/ a t ... f a ) 

1 2 n 

be an execution sequence in a flowgraph. Tc each arc a , 

i 
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there corresponds a mapping 

x into output variables y , 
k 1 

relationship is denoted by 
as a subgraph. 



of input variables x 

1 

y , . . . , y . Ihis 
2 m 

some operation c and 

i 



• * > • • ■ * 

2 

functional 

indicated 




If one or mere of the input variables of o is identical to 

i 

an output variable of some ether operation o , then we 

3 

identify such variables by the same vertex in the data 

flowgraph. Similarly, if there is a common input or output 
variable to one or more operations o , we identify such 

j 

variables by the same vertex in the data flowgraph. If this 



procedure 

execution 

flowgraph 



is successively carried out 
sequence S, the resulting 



for each arc 
graph is a 



of S. 



in the 
data 



he have given so far very simple examples to 
illustrate the idea of a data flowgraph. It is easy to see 
that in a complex program there are large numbers of 
execution sequences and hence data flowgraphs. Therefore 
this method of analysis would become so complex that it 
becomes useless. 



Fortunately the idea of a data flowgraph lends 
itself very naturally to levels of abstraction. he can 
illustrate this with the example wnich comes from the A6-E 
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tactical system 



3 . An Illu st r ativ e Real Time Sys tem 



a. Eata Flcwgraph Construction 



An attack aircraft (A6-E) tactical system is 
used to illustrate the flowchart and data flcwgraph analysis 
technigues . 
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FIG.V.B.3 A6-E TACTICAL PROGRAM FLOWCHART 
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Cne execution of the infinite loop, that is, the 
transition from the control point above Steering 
Commands..." to the control point below Ballistics 
Calculations..." in Fig. V.B.3, may be regarded either as a 
set of all possible execution sequences, or as a single 
transition cf control. If we regard it as a single 
transition cf control, then we can represent what happens to 
the data with a single data flcwgraph as shown in Fig. 
V.E.4. This representation corresponds to the overall view 
cf what the program does. Each data set vertex represents 
data items which serve as inputs or outputs of the system, 
whereas the operation carried out by the systeir is 
represented by a single vertex, a box in which the operation 
is described in English. 
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FIG.V.B.4 DATA FLOWGRAPH OF THE A6-E TACTICAL SYSTEM 

If we wish to consider a more detailed view of 
the operation under the same transition cf control, then 
each distinct execution sequence gives rise to a data 
flowgraph and the set cf all such data flowgraphs describe 
in more detail what the single flowgraph expresses in Fig. 
V. E.4 . 
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The Navigational Subsystem consists of eight sequential 
steps in Fig. V.B.5. the first step is entitled Air Data 
Quantities- 1 in Fig. V.B. 6. This flowchart gives the finest 
level of detail and enables a programmer to translate the 
flowchart to a higher level language or an assembly language 
program . 




FIG. V. Up FLOWCHART OF THE NAVIGATIONAL SUBSYSTEM 
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Corresponding tc the flowchart in Fig. V.E.6 we 
construct a flowgraph in Fig. V.B.7. In the flowgraph we 
have distinguished between the vertices from which more than 
cne arc issues. The latter vertices are symbolized by a 
small diamond indicating that several execution sequences 
emanate from that vertex. 

he also distinguish between twc types cf arcs: 
cne (syaicli 2 ed by a square) corresponds tc a statement 
which permanently alters a data value; the ether (symbolized 
by an arrow) corresponds to a transition in control which 
dees not permanently alxer any data values. 

Ihe heavy arcs constitute a spanning tree cf the 
flowgraph which is of significance in execution time 
analysis as well as control complexity analysis. 

Further simplification of the analysis can be 

obtained by subdividing the flowgraph into sc-called control 

segments, which are segments of a program with a single 

entry and single exit. The control segment from v to v in 

0 5 

Fig. V.B.7 is shown in the flowchart form in Fig. V.E.8, and 



in the flcwgraph form inV.B. 


9(a) . 








As before, we 


can 


gene 


rate a data 


flowgraph 


which describes an overview 


of 


what 


takes plac 


e in the 


control segment, as shown 


in 


Fig . 


V. E . 10. 


If we are 



interested in more detail, then we look at all possible 
execution sequences which are desribed as a rooted tree in 
Fig. V.B.9(b). Corresponding to the six possible execution 
sequences, there are five distinct statement sequences and 
their corresponding data flowgraphs in Fig. V.B.11. 
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FIG.V.B.6 FLOWCHART OF AIR DATA QUANTITIES-1 
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First Control 
Segment 



Second Control 
Segment 



Third Control 
Segment 

a 

v 

a 2 2 



FIG. V.B.7 




flowgrapii of air DATA QUANTITIES- 1 
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FIG. V. B . 3 FIRST CONTROL SEGMENT OF AIR DATA QUANTITIES-1 
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FIG.V.B.10 DATA FLOWGRAPH OF FIRST CONTROL SEGMENT 
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FIG.V.B.9' FLOWGRAPH AND EXECUTION SEQUENCE TREE 
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FIG. V . B . 11 DATA FLOWGRAPHS CORRESPONDING TO FIVE STATEMENT SEQUENCES 
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can similarly 



The control segment v to v 

5 7 



be 



described in flowchart form in Fig. V.B.12., as an overview 
in Fig. V.B.13, or in complete detail as in Eig. v.E. 14(a), 

<t) • 



Ihe control segment from v to v is shown in 

7 15 

flowchart fcrm in Fig. V.E.15 and as an overall data 

flcwgraph in Fig. V.B.16. The overall view cf the entire 
page and how the control segments fit together is displayed 
in Fig. V.3 . 17. 



If a program contains a lcop, then the 
corresponding flowgraph is a repetition of flowgraphs each 
of which describes the data flew for a single transition of 
control . 

Ke wish to note that in the A6-E tactical 
program there are about sixty pages of f lo wcharts-some less 
complex, some more complex . The page used tc illustrate the 
data flowgraph concept is thus a small but sufficiently 
complex example to illustrate the usefulness in: 



(a) analyzing parallel processing, 
<t) test case preparation, 

(c) error analysis, 

(d) program verification. 
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Fig .V. B . 12 FLOWCHART OF SECOND CONTROL SEGMENT 
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Fig. V. 3. 13 SECOND CONTROL SEGMENT'S DATA FLOWGRAPH 
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Fig . V. B ,14 DETAILED SECOND CONTROL SEGMENT'S DATA FLOWGRAPH 
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FIG .V . B . 15 FLOWCHART OF CONTROL SEGMENT THREE 
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FIG. V. 3. 16 OVERVIEW DATA FLOWGRAPII OF SEGMENT THREE 
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IG.V.B.13 data flowgraph describing three control segments of 

AIR DATA QUANTITIES- 1 
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• Anal y sis of Parallel Eroc ess inq 



The nain concerns in distributing a process among 
several computers is the resulting inefficiencies introduced 
by the distribution: 

(1) greater communication problems between 
computers ; 

(2) duplication of data and programs; 

(3) imbalance in execution times and program size 
among the processors. 

Ihe data flowgraphs allow us to explicitly determine 
the number of data elements which must be communicated to 
ether processes. 

In Fig. V.B.17 the data fiowgraph shows that the 
Eressure Altitude Calculations have no data values in common 
with the Mach Number Calculations. He can conclude that 
these processes could be carried out in different computers 
completely independently without creating communications 
problems. The same graph also shows that the Effective 
Temperature Calculations use two data values generated by 
Mach Number Calculations and two data values from Eressure 
Altitude Calculations. If a single computer must sclve the 
problem# then eight data values are used as inputs and five 
values are used as outputs. If two computers are to sclve 
the problem, and if Mach Number Calculations are done in one 
computer and the Pressure Altitude and Effective Temperature 
Calculations are dene in the ether, then the communication 
problems are increased by the two data values which must be 
communicated. Effective Temperature Calculations may not be 
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started tefcre dach Number Calculations are ready. This 
causes timing problems in addition tc communication 
problems; however, data flowgraphs allow the analysis of 
hcth problems. 

Data flowgraphs reduce the distributed system design 
problem to a graph partitioning problem with side 
constraints. Several effective algorithms exist for solving 
that problem. Reference [2] reviews the published 
literature on graph partitioning. The side constraints may 
be taken to be program size and maximal execution time. The 
problem then becomes: Partition rhe graph into a minimal 
number of partition elements so that the number of arcs cut 
is minimized, and the bounds on program size and maximal 
execution times are satisfied. The problem is completely 
analogous tc the hardware partitioning problem for creating 
mother-beards in computer design. the mother-board design 
problem had to satisfy input-output constraints which 

certain maximum number of input-output 
each mother-board, as well as a certain 



permitted only a 
connections for 



maximum number of daughter-cards on each mother-board. 

5 • lest Case Prepa rati on 

As all of us who write computer programs knew, a 
program is seldom correct when first executed. Therefore it 
is safe to assume that programs contain errors, and we would 
like to generate test cases which are: 

(1) exhaustive enough to discover all errors; 

(2) small enough in number sc that we can 
effectively test the cases; 



(3) suggestive of what must be done to naice 
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corrections 
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uter programming is in many ways analogou 
vation in solving calculus problems. The 
gains confidence in a lengthy derivation 
ne answer section to see if the result ob 
the one given in the book. If the r 
we usually are satisfied. If net, then w 
h equivalence. Failing that, we check alg 
s, signs, differentiations, integrations, 
error is discovered. If we work 
d problem which does not have an answer i 
s book, we resort to different schemes, 
nd we call him to find out what resu 
f the results do not agree, we check back 
cits first disagreed. 
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In programming we use similar techniques. We write a 
in seme higher level language such as FORTRAN. If 
te a special purpose routine to evaluate a 
etric function, we compare our results with the 
nding library routine. How many test values do we 
we have a polynomial of degree n, then theory tells 
n+1 points are sufficient to establish identity. By 
random number generator to generate a set of n+1 
numbers in the interval of interest and by finding 
results agree with sufficient accuracy, we become 
t that no further errors exist. We remain confident 
meone discovers that for a particular case the 
are incorrect. we fix the program and add these 
ar cases to our repertoire of test cases. Usually 
cints of finite intervals, zero value, or undetected 
ws and overflows are a cause of trouble. How does 
flowgraph concept help us generate test cases? 



We observed in the previous segment that the control 
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segment v to v had six different execution sequences and 
0 5 

five different statement sequences. Each statement seguence 

gives rise to a different function. Therefore we must 
prepare at least five different data sets, one fcr each 
function. As shown in Fig. V.B.11 each function is a 

constant function, and hence theoretically, cne data value 
ror eacn data set would be sufficient to check identity to a 
previously computed constant function. 

If cne considers the flowgraph in Fig. V.B.7 in its 

entirety, then the tctal number of execution sequences 

between v and v is 72. The number of execution sequences 
0 15 

may be calculated by a vertex labelling algorithm which 
labels each vertex with the number of distinct access paths 
from the entry point. 

Because several execution sequences give rise tc the 
same statement sequence, cnly 50 distinct statement 
sequences exist. If each statement sequence yielded a 
unigue function, we would have to construct at least 50 
different data sets, each data set containing at least one 
set of values. In the A6-E tactical program there are 60 
pages of flowcharts of control complexity with about an 
average of 20 statement sequences each. Therefore, there 
are approxi nately (20) 60 statement sequences in the entire 
program. If each statement sequence gave rise tc a 
different function, we would have to generate (20) 60 data 
sets, each containing at least one set cf data values. 
Clearly testing the pregram would become impossible. 

The data flowgraph corresponding tc the ccntrol 

segment (i.e. a program segment with a single entry and a 

single exit) from v tc v in Fig. V.B.10 is disconnected 

0 5 
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from the data flowgraph for the next control segment. This 

means that the two functions are independent and can be 
tested independently from each ether. 

1 fcecretically , the first control segment requires 5 
data sets, the second 2 data sets. Altogether 5+2 data 
sets are necessary instead of 5*2 = 10. 

The third control segment is a rational function 
containing 5 statement sequences. Hence 5 data sets wculd 
need to be constructed to test out that function. 



In 



order that two rational functions be identical, 
B1/H2 = Q1/Q2 



it is sufficient tc form the 



product polynomial. 



B 1 * Q2 = Q 1 * R2 

If the twe product polynomials are equal 
except possibly the points at which the dene 
then we car conclude that the rational 
identical. In the above example, four data 
set would be sufficient. Thus 5 + 2 + 5 = 1 
sufficient tc test the identity of the func 
in the fiewgraph in Fig. V.3.7 instead of th 
estimated cn the basis of the statement 
flowgraph . 



fer all values 
minators vanish, 
functions are 
values per data 
2 data sets are 
tions calculated 
e 50 data sets 
sequences in the 



The flowchart page used in this example has average 
complexity. If we assume that the complexity of each page 
is on the average similar to this page and that data 
flowgraphs exhibit the same degree of independence as they 
do on this page, then cnly 
oC * 12 = 720 

data sets need to be constructed instead of (20) 60 . Clearly 
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720 data sets would be a reasonable number tc construct even 
if each data set contained 10 sets of data values. 



6 . Error Analysis 

The data xiowgraphs lend themselves to numerical 
error analysis. Dorn an McCracken [5] presert an elementary 
tut complete treatment of roundoff error propagation for 
coth fixed-point and floating-point arithmetic. They use 
data flowgraphs (or process graphs in their terminology) to 
develop the error-bound estimates for each function. We 
shall not repeat their presentation here but refer the 
reader to their book. 

In addition tc numerical error-bound analysis, data 

flowgraphs give strong indications of possible trouble spots 

or errors in the program. For example, in the statement 

sequence S S S in Fig.V. B . llyariable M is set to M in 

247 n-1 

S and rest to M in S S . Althougn the function nay be 
2 m-1 4 7 

correctly calculated, it is dene clearly in an inefficient 

fashion. It is not hard tc reconstruct the program to 
eliminate this inefficiency and still cctrpute the same 
function . 



7 • Program Ve rif i cati on 

For real time tactical systems, program verification 
is particularly difficult to accomplish. In order to verify 
that a program does what is intended, there must be an 
unambiguous statement of intention. frequently the 
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statement 



cf intention is in a flcwcnart form. Eecause 
flowcharts imply a sequence cf statements and a sequence of 
controls, the statement of intention not only specifies what 
is wanted, but also in what sequence it shculd occur. This 
cver-specif ies the program, causes inefficiency, and removes 
useful flexitility. 

Erogram verification, as described by Hantler and 
King [10], consists of: 

(1) stating formally what assumptions are made about 
input variables before entry intc a procedure; 

(2) asserting algebraically or by logical statements 
what the output variables will contain when the procedure is 
completed ; 

(3) symbolically executing the program as described 
in some programming language to show that the results agree 
with the specification. The data flowgraph is a graphic 
expression cf one cr more algebraic statements. Therefore 
algebraic statements can be interpreted into data 
flowgraphs. This allows us to construct a data flowgraph or 
a set of data flowgraphs for the specification statement. 



The symbolic execution cf a program is equival 
the process of constructing a data flcwcraph for 
execution sequence in the program. The verification p 
is the process of checking whether or not the 
flowgraphs ccrresp onding to the specification are equi 
to the data flowgraphs obtained from the exe 
sequences . 



ent to 
each 
recess 
data 
valent 
cution 



An automated process of showing equivalence is by nc 
means an easy process to construct. Conceptually, however, 
data flowgraphs will enhance program verification. 
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a. 



Summary 



This segment introduces the data flcwgraph concept 
as a useful tool in the analysis of real time systems. 
Although there are mere applications, this segment has 
focused attention on four applications which are 
particularly useful in systems analysis: 

(1) process partitioning into sutprocesses for 
distributed processing; 



(2) generating test cases to establish that the 
program under design is identical to a known, correctly 
functioning test program; 

(3) rumerical error analysis and the analysis of 
inef f iciences occurring in the program; 



(4) program verification. 

The data flowgraph is useful conceptually as well as 
in the practical domain of implementation of algorithms to 
carry out the automated analysis tasks. 



C. EXECUTION TINE ESTIMATING 



In Section V.A the theoretical aspects of execution time 
estimating were given. An analysis tool which generates the 
formula for execution times in terms of the linearly 
independent flow variables could be developed as part cf the 
program compilation process. Presently this tool is not yet 
available . 
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Our analysis for the A 6-E operational flight program was 
carried out by manual methods. The entire flowchart cf the 
program is a collection of flowcharts one per page. The 
majority of the pages contain a single entry point and a 
single exit point. By looking at the operations indicated 
by formulas, it is not hard to determine among all possible 
execution sequences the one which consumes the maximum 
amount of execution time. It is that one which was used to 
estimate the worst case execution rimes for each pace of 
flowchart. k n upper bound for the worst case execution time 
can be octaiced by summing the maximal execution times of 
each program segment. It may be that such an execution 
sequence is never realized in practice and therefore the 
upper bound measure is pessimistic. Ihis is a way of 
insuring that the program execution never exceed the upper 
bound value. The values in the tables for the A6-E 
operational program were generated in this way. The 
breakdown into fixed point and floaring point operations was 
chosen because floating point hardware units are presently 
available for LSI computers at a low cost. Using floating 
point, arithmetic enhances accuracy and makes programming 
easier. 



C . PROGRAM AND DATA REQUIREMENTS 

In order to determine program length requirements, each 
page of the A6-E operational program flowchart was used and 
the number of instructions estimated. Because the actual 
A6-E program does net use floating point arithmetic the 
estimated program length differs somewhat from the actual 
program length. A floating point instruction does not 
require shifting operations because this is done in the 
hardware processor. Consequently the actual program length 
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is about 20% longer than our estimate predicts. 

Ihe data requirements for our estimates were based on 
the number cf variabes used in the programs. The floating 
point format is assumed to be a 32 bit form used by the I3M 
computers as well as the LSI computers. For the presently 
available LSI computers, the floating point unit is treated 
as an input-output device accessible on the systems data 
bus. The constants are also accounted for in the totals. 

For distributed systems, it may be more efficient from 
the execution time and bus use point cf view to duplicate 
constants and function subprograms in each of the 
processors. In our analysis we have assumed that this is 
done. Furthermore, each processor will also have a small 
operating system which also is duplicated in each single 
board computer. Although this is not necessary in 
distributed systems design, it is dene to create 
independence of each processor on the bus. Ihe failure of 
any single beard computer will not cause the failure cf tne 
system . 



E. PARTITIONING METHCEOLOGY 



The logical cchesiveness of a program is shown by the 
data flow analysis. The data flow analysis allows us to 
determine precisely these variables which must be shared by 
ether segments of the program. This analysis was carried 
cut painstakingly for the A6-E operational pregram. 
Development of software tools to make this analysis 
automatic and part of the compilation process is very useful 
fer the partitioning process. 
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Our partitioning methodology was based cn the concept of 
this logical cohesiveness. Logical cohesiveness is a 
natural byproduct of a well written program. The data flow 
analysis allows us to discover logical cohesiveness even in 
a program which is not written with that in mind, 
furthermore, logical cohesiveness reduces the number of 
variables which are transmitted tc other processes. 
Iherefore, the bus use is minimized, or eguivalently , the 
parameter count passed to subprograms is minimized. There 
may be other considerations of importance in the 
partitioning process. If we wish to design systems which 
continue to function even when one of the processors 
malfunctions, then a simple way of accomplishing this is to 
place a process in more than one processor. This is 
analogous to having a pilot and copilot cn a commercial 
airliner for safety. All the vital functions can be 
distributed so that the failure of any one processor will 
net cause failure of any vital function. 



Program and data length also must be considered i 
partitioning process. If programs and data are 
distributed, it is important that the program and dat 
into the computer. Although expansion of memory is 
achieved with the LSI architectures, the access time t 
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expanded mercery is slightly greater and there is contention 
among processors for the use of the system's bus. 



The execution time of the process must te conside 
the most important factor. The processes mus 
distributed so that each process can be ex 
successfully a prescribed number of times per second, 
cf course is a very important aspect of real time sy 
All of the above considerations are used in the partit 
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process . 
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VI. FUNCTIONAL descbietion of the 


VSTOL 


SYSTEM 




w e 


develop the functional 


requirements 


for 


the VSTOL 


system 


by examining in detail the avioni 


cs syst 


em f cr 


the 


A6-E. 


Other existing systems 


A7-E, P3-C, 


S3-A, 


F-15, 


and 


1 

t 

00 


are contrasted with 


respect to 


the 


A6-E. 


We 


characterize the functional 


requirements 


in 


terras 


of 


arithmetic complexity. 


control 


c 


ompl exity , 



intercommunication requirement, program size, and data 
storage size. We identify the core elements of tactical 
systems, that is, these functional elements which all cf the 
systems share. Two of the VSTOL applications fighter/attach 
version and the antisubmarine warfare version are 
functionally quite different. However, the functional 
similarity of the VSTCL versions to their corresponding 
fixed wing cousins is great. The essential difference 
between VSI01 and fixed wing aircraft is in the takeoff and 
landing controls. 

A . OVERVIEW OF THE ATTACK AIRCBAFT TACTICAL SYSTEMS 

The primary purpose of the Navy attack aircraft is to 
provide close air support to forces operating on land. The 
A6-E and A7-E are the presently employed attack aircraft 
which use an on-board computer based tactical system. We 
have chosen the tactical system of the A6-E as a model 
because its documentation was most easy to use for our 
analysis. The most significant functional difference 
between the A6-E and A7-E is that the A7-E is manned by the 
pilot alone, whereas the A6-E has a pilot and a 
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tcmbardier/navigat cr . Both systems use functionally 
identical sensors to help navigate and track the target. 
Ihey are designed tc carry the some armaments which include 
free fall bombs, rockets and retarded acceleration weapons. 
Although the same ballistics problem has to be solved in 
both cases, the numerical techniques of doing that are 
different . 

He describe the A6-E system in sufficient detail sc that 
cur estimates and extrapolation are based on reality rather 
than on an assumed hypothetical model. The A6-E system is 
documented in two documents, one which describes the 
flowchart [18] and the other which describes the system 
functionally [19]. The assembly language version of the 
operational flight program (OFP) was also used. 



1 • ii-E Tactica l Syst em 

Ihe operational flight program performs the 
following fuctions: 

a) Navigational Calculations 

b) Tracking and Ranging Calculations 

c) Eallistics Calculations 

a) Sensor Input/Output and Steering 

a. Navigational Calculations 

The sensors used to generate information to the 
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navigational system are: the inertial navigational 

equipment, the aoppler radar equipment, the magnetic 

compass, the airspeed indicator, and the altimeter. The 

intertial navigation subsystem (INS) contains accelerometers 

which are able to measure accelerations alcng three mutually 

perpendicular axis (x,y,z) . These measured accelerations 

are integrated by analog circuitry into velocity components, 

v , v , v which are converted Dy analog to digital 
x y z 

converters into digital information which is placed into 
computers memory at the fixed rate of 20 times per second. 

Similarly, the Doppler radar measures analog 
information which is converted into digital information, 
namely, the velocity component along the ground track, and 
the angle between aircraft heading and the ground track. 
Finally, the magnetic compass reading is converted into 
digital information along with the airspeed and altimeter 
readings . 

It is important to distinguish between accuracy 
and precision. Accuracy would be a measure associated with 
how close the reading of the instrument would be to a 
carefully calibrated instrument. The precision is related 
to the number of binary digits which are generated. The 
precision of the instruments is 12 binary digits or less. 
The accuracy is dependent on calibration and generally is 10 
binary digits or less. There are systemic errors such as 
the Schuler pendulum effect which depends cn how carefully 
the gyroscopes are stabilized before the flight takes place. 
The digital systems can by used to aid in the calibration 
process and the Schuler pendulum effect is partially 
neutralized by a digital to analog signal which is fed tack 
tc the accelerometers. 



Unfortunately errors are neither random ncr are 
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they purely due to bias, therefore it is net possible to 
improve the ten binary digit accuracy unless the sensor 
instruments are improved. Increased accuracy and precision, 
however, is extremely expensive. 

Ihe navigational system operates in four medes 
depending cn the confidence that the pilot and 
bembardier/na vigator have in the instruments. If the 
inertial navigational system and Doppler radar are both 
operational and do not give mutually conflicting data, this 
mode is considered most accurate. If one or the other is 
suspected of inaccuracy, the two more modes result, inertial 
alone or Eoppler alone. In case of failure cf both systems, 
the magnetic compass and airspeed with a manual correction 
for wind velocity is used. The navigator is the backup for 
all four modes failing. 

The computer program for the navigational 
function is subdivided into nine segments, each segment is 
documented as a flowchart page as well as two to five pages 
of assembly language program. Me have extracted from each 
flowchart page the basic operation counts in the program. 
Eecause the 36-E computer (IEM 4Pi) has no floating point 
arithmetic, the assembly language program uses scaled 
arithmetic. In the flcwchart, however, it is quite clear 
which variables correspond to floating point numbers and 
which variables are fixed point and/or logical variables, 
lable VI. 1-6. contains the breakdown of each page cf the 
flowchart with a count of each type of instruction as well 
as the number of calls to library subroutines. The two rows 
corresponding to the flowchart page are the instruction 
counts in the execution path which would be the most time 
consuming execution path in the upper row and the total 
instruction count on the page in the lower row. 

The column headings refer to the instruction 
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types categorized as fellows. 



C-Conaitional branch for integer operands 
I/S-Load or Store an integer 

CF-Conditicnal branch for Floating point 

operands 

ISF-Load or Store a Floating point operand 

FAD-Floating point ADd 

FMU-Floating point Multiply 

FCV-Floating point Divide 

CC-COsine function 

Sl-SIne function 

Al-Arc Tangent function 

IN-Logar it hmic fuNction 

SQ-SQuare root function 

KU-the number of independent cycles in the 

f lowgraph 



ES-tha number of distinct execution sequences in 
the flowgraph 

The last two columns deal with control 
complexity measures which have a close relation tc the 
number of tests required to verify program identity tc a 
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given program. These concepts are discussed in Chapter V. 
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TABLE VI. 1 A6-E NAVIGATIONAL 
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TABLE VI. 2 A6-E INPUT/OUTPUT 
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TABLE VI. 4 A6-E TRACKING AND 
RANGING FUNCTION 
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0 


0 


0 






jEW 


8 


12 


2 


49 


16 


10 


4 


1 


1 


0 


0 


0 


13 


136 


'DATE 2 


14 


24 


2 


87 


18 


10 


4 


1 


1 


0 


0 


0 






(GLE 


2 


4 


4 


44 


12 


13 


5 


2 


1 


0 


0 


0 


7 


16 


TES 


2 


7 


5 


62 


13 


16 


6 


2 


1 


0 


0 


0 






'RSOR 


2 


2 


1 


87 


49 


32 


12 


4 


4 


3 


0 


2 


7 


13 


DATES 


6 


8 


1 


125 


52 


37 


14 


5 


4 


4 


0 


4 






DAR 


1 


10 


3 


26 


0 


0 


0 


0 


0 


0 


0 


0 


4 


8 


TPUTS 


1 


10 


3 


26 


0 


0 


0 


0 


0 


0 


0 


0 






RGET POS 


1 


3 


0 


46 


15 


11 


3 


1 


1 


2 


0 


1 


1 


2 


DATES 


1 


3 


0 


46 


15 


11 


3 


1 


1 


2 


0 


1 






TALS 


32 


75 


10 


453 


124 


82 


32 


8 


7 


5 


0 


3 


51 


io 9 




45 


134 


11 


595 


138 


95 


38 


9 


8 


6 


0 


5 














TABLE VI. 


5. A- 


6E TARGET 


UPDATES 
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RESELECT 



C 

8 



L/S CF LFS FAD FMU FDV CO SI AT 



LOGICl 


9 


31 


0 


0 


0 


0 


RESELECT 


5 


11 


0 


0 


0 


0 


LOGIC2 


14 


30 


0 


4 


0 


0 


RESELECT 


7 


8 


0 


0 


0 


0 


LOGIC3 


11 


25 


0 


3 


0 


0 


RESELECT 


10 


14 


0 


0 


0 


0 


LOGIC4 


20 


36 


0 


0 


0 


0 


RESELECT 


8 


10 


0 


0 


0 


0 


LOGIC5 


16 


30 


0 


0 


0 


0 


ATTACK 


7 


11 


3 


15 


2 


2 


SELECTl 


8 


25 


3 


25 


6 


3 


ATTACK 


6 


23 


0 


22 


5 


5 


SELECT 2 


10 


40 


0 


38 


7 


5 


STEP OUT 


2 


2 


7 


15 


6 


1 


OF ATTACK 


9 


19 


10 


18 


6 


1 


ATTACK 


5 


7 


10 


16 


4 


2 


VALIDl 


6 


34 


11 


17 


5 


2 


ATTACK 


7 


9 


4 


24 


12 


2 


VALID2 


10 


20 


5 


39 


18 


3 


TOTALS 


65 


94 


24 


92 


29 


12 




113 


290 


29 


144 


42 


14 



0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1 

1 

1 

0 

0 

2 

2 

4 

5 



0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

0 

0 

0 

0 

1 

1 



0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

0 

0 

0 

0 

1 

1 



0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

0 

0 

1 

1 



TABLE VI. 6. A6-E ATTACK DECISIONS 



LN SQ 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

1 0 

1 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

0 0 

1 0 

1 0 



MU ES 

9 45 

14 19 
11 16 
20 62 

16 17 

11 33 

10 72 

19 102 

17 286 

15 84 

17 

142 10 
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We chose floating point operations to 
characterize the program because the essential reason why 
floating point operations have not been used in tactical 
computing has been that hardware floating point arithmetic 
has been toe expensive to inplement. The expense has 
changed radically with the LSI chips with the present cost 
range between $200 - $5000 for the floating point unit. The 
AN/UYK-14 and the AN/UYK-20 both have floating point 
options. 

In Table VI 7-12 we have tabulated the number of 
FORTRAN or CMS-2 instructions (if the flowchart were 
translated into FORTRAN or CMS-2) in the categories of 
arithmetic (AS) , conditional (IF) and control alteration 
(GO) statements. In addition we have given the number of 
assembly language instruction in the actual program and the 
number of bytes (8 bits) the program occupies in memory. 
The number of CMS-2 statements would be the same as in 
FORTRAN except that each variable in CMS-2 has to be defined 
in an additional statement. 

We include the FORTRAN and CMS-2 versions for 
purposes of comparison with the assembly language program. 
We draw some conclusions as to relative efficiencies of 
programming at the end of this chapter. 

Cne surprising fact is the large number of 
possible execution sequences which appear in the 
navigational program, namely 10 9 . The number of execution 
seguences is related to the number of different functions 
calculated in this program segment. As is seen in Chapter 
V, the functional segments are independent cf each other and 
the total number of distinct functions calculated by the 
navigational program is far less than 10 9 . Ey reorganizing 
the program, it is also possible to reduce the number of 
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execution sequences 





AR 


IF 


GO 


TOTAL 


ASSEMBLY 


BYTES 


AIR DATAl 


19 


9 


6 


34 


118 


242 


AIR DATA 2 


20 


2 


1 


23 


87 


168 


AIR MASS 
ANGLES 


15 


10 


2 


27 


124 


272 


DOPPLER 

VELOCITY 


16 


5 


4 


25 


90 


176 


SYSTEM 

VELOCITY 


26 


4 


4 


34 


115 


232 


BARO INRT 
VERT LOOP 


25 


9 


6 


40 


127 


270 


INERTIAL 

ANGLES 


16 


3 


2 


21 


78 


168 


PLATFORM 
CORRECTIONS 1 


17 


2 


2 


21 


100 


200 


PLATFORM 
CORRECTS 2 


28 


1 


1 


30 


243 


488 


TOTALS 


182 


45 


28 


255 


1082 


2216 



TABLE VI. 7. A6-E NAVIGATION 
HIGHER LEVEL LANGUAGE COMPLEXITY 
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AR 


IF 


GO 


TOTAL 


ASSEMBLY 


BYTES 


COMMAND 

STEERINGl 


33 


4 


4 


41 


109 


242 


COMMAND 

STEERING2 


33 


9 


7 


49 


188 


430 


COMMAND 

STEERING3 


23 


6 


5 


39 


99 


318 


SAMPLE 

INPUTS 


52 


1 


1 


54 


272 


482 


INTERRUPT 

SERVICE 


30 


8 


7 


45 


147 


376 


STEERING 

DISPLAY 


23 


6 


4 


33 


127 


252 


DISCRETE 

OUTPUTS 


46 


2 


2 


50 


254 


552 


STEERING 
KEY SELl 


18 


8 


5 


31 






STEERING 
KEY SEL2 


38 


10 


10 


58 


255 


588 


TOTALS 


301 


54 


45 


400 


1451 


3240 



TABLE VI. 8. A6-E INPUT/OUTPUT 
AND STEERING HIGHER LEVEL 
LANGUAGE COMPLEXITY 
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AR 


IF 


GO 


TOTAL 


ASSEMBLY 


BYTES 


ROCKET 

ATTACK1 


26 


5 


3 


34 


113 


252 


ROCKET 

ATTACK2 


16 


2 


3 


21 


100 


216 


BOMB 

ATTACK1 


13 


3 


3 


19 


62 


136 


BOMB 

ATTACK2 


38 


9 


2 


49 


240 


480 


BOMB 

ATTACK3 


29 


3 


3 


35 


261 


532 


BOMB 

ATTACK4 


22 


9 


4 


35 


164 


356 


BOMB 

ATTACK5 


15 


9 


7 


31 


73 


168 


BOMB 
AT TACK 6 


17 


14 


7 


38 


98 


224 


BOMB 

ATTACK7 


38 


15 


11 


64 


229 


498 


COMMON 

DRAG 


21 


5 


3 


29 


209 


434 


TOTALS 


235 


74 


46 


355 


1549 


3296 



TABLE VI. 9. A6-EBALLISTICS FUNCTION 
HIGHER LEVEL LANGUAGE COMPLEXITY 
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AR 



IF 



GO TOTAL 



ASSEMBLY 



BYTES 



GREAT CIRC 
NAVIGATION 



TRACK RADAR 
TESTS 



DEPR ANGLE 
TRACKING- 1 



TRACK SCAN 
TESTS 



DEPR ANGLE 
TRACKING- 2 



LINE OF SIGHT 
RANGl 



14 0 0 



13 9 7 



10 12 10 



21 9 5 



22 9 9 



26 8 4 



14 82 



29 78 



32 102 



35 157 



40 112 



38 159 



LINE OF SIGHT 19 13 7 39 107 

RANG 2 



SHRIKE 28 13 8 49 138 

RANGING 



RADAR 23 13 10 46 131 

RANGING 



TOTALS 232 104 75 411 1321 



TABLE VI. 10. A6-E TRACKING AND 
RANGING FUNCTION HIGHER 
LEVEL LANGUAGE COMPLEXITY 



164 



174 



250 



338 



268 



322 



244 



300 



284 



2932 



119 





AR 


IF 


GO 


TOTAL 


ASSEMBLY 


BYTES 


TARGET 

INITIALIZE 


50 


6 


5 


61 


152 


306 


TARGET POS 
FILTERS 1 


43 


7 


5 


55 


216 


490 


TARGET POS 
FILTERS 2 


10 


2 


1 


13 


15 


36 


SLEW 
UPDATE 1 


17 


5 


5 


27 


50 


102 


SLEW 
UP DATE 2 


46 


16 


8 


70 


189 


396 


ANGLE 

RATES 


27 


7 


3 


37 


136 


284 


CURSOR 

UPDATES 


38 


7 


3 


48 


316 


678 


RADAR 

OUTPUTS 


15 


4 


3 


22 


86 


230 


TARGET POS 
UPDATES 


18 


1 


0 


19 


88 


176 


TOTALS 


264 


55 


33 


352 


1248 


2698 



TABLE VI. 11. A-6E TARGET UPDATES 
HIGHER LEVEL LANGUAGE COMPLEXITY 
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AR 



IF 



GO TOTAL 



ASSEMBLY 



BYTES 



RESELECT 

LOGICl 


14 


10 


5 


-v 

29 






RESELECT 

LOGIC2 


24 


15 


12 


51 






RESELECT 

LOGIC4 


14 


20 


8 


42 1 






RESLECT 

LOGIC5 


10 


16 


6 


32 / 


583 


1324 


ATTACK 

SELECT1 


29 


11 


4 


44 


161 


390 


ATTACK 

SELECT2 


28 


10 


6 


44 


100 


236 


STEP OUT 
OF ATTACK 


11 


19 


5 


35 


81 


208 


ATTACK 

VALID1 


25 


17 


12 


54 


145 


342 


ATTACK 
VALID 2 


26 


15 


5 


46 


148 


360 


TOTALS 


202 


144 


69 


415 


1218 


2860 




TABLE 


VI .12. 


A6-E 


ATTACK 


DECISIONS 





HIGHER LEVEL LANGUAGE COMPLEXITY 



2 



Tracking and Fan qing Ca lcula tions 



1 he 

establish th 
airplane . 
positions in 
computer f 
sufficiently 
appear cn 
his cursor c 
calculations 
necessary tc 
line along w 
bomb or rock 
VI. 5, and 



purpose of this segment of 
e position of the target with 
At the start of a mission 
a sequential order can be i 
rom the keyboard. Once 
close to a target so that the 
the radar display allow the b 
n the target, then the rang 
are made in a local coordin 
determine the velocity of a m 
hich the aircraft should move 
et would hit the target. Ta 
VI. 6 give the complexity m 



calculations . 



3 . Ealli stic s Ca lc ula tio ns 

I he ballistics calculations det 
initial conditions at release the down ra 
time of fall cf any particular weapon. F r 
point of view this corresponds to sclv 
ncn-linear differential equation with 
conditions: the initial position of th 

initial air velocity of the aircraft, 
procedure used in the ballistics algcrit 
approximations rather than an integration 
the differential equations. This is 
execution time cf the program. The balli 
are described in Table VI. 7 andVI.8. T 
contain the attack decision making process 
this process is not demanding. Howev 



the program is tc 
respect tc the 
up to four target 
nserted into the 
the aircraft is 
landmarks which 
cmhardier to place 
ing and tracking 
ate system. It is 
cving target, the 
sc that a released 
ties VI. 3, VI. 4, 
easure for these 



ermine from the 
nge travel and the 
cm a mathematical 
ing a second order 
given initial 
e aircraft and the 
The numerical 
hra uses polynomial 
method for solving 
dene to reduce the 
Stic calculations 
able VI. 9 ancvi.10 
. Arithmetically 
er, from ccntrcl 
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complexity pcint of view this is a difficult process xo 
test. It certains 10 17 execution sequences. 

4 . Sensor I/O and Steer ing 

This segment of the program controls the analog to 
digital converter. The conversion is interrupt driven at 
the rate cx 20 times per second. The data is gathered and 
smoothed for processing at the update rate of 5 times per 
second. The update rare of 5 times per second is used for 
all processes other than the data gathering function. The 
analog and digital outputs are also generated ir. this 
program segment. The digital to analog conversion is done 
under ' the control of the computer. Correction signals to 
inertial navigation unit, radar antenna control, display 
ccntrol and steering command are generated by this segment. 
Tables VI. 11 and VI. 12 contain the complexity parameters. 

«e can express the entire functional requirements of 
the A6-E operational flight program by the Table VI. 13. The 
headings are described as follows: 

S-Shcrt instructions, 16 bit integers 

2-Medium length instr uctions : lead, store, and 

compare floating pcint quantities 

I-Iong floating instructions: EAD, EMU, FDV 

X-Suhprogr ams which calculate sines, cosines, etc. 

INIG-number of integer variables in the program 

BEAL-number of floating point variables in the 

program 
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EXT-nuober of variables which are 

used by other programs 
external to the named one. 



Instructions Variables External 





S 


M 


L 


X 


Int 


Real 


Int 


Real 


Navigational 


51 


3 02 


225 


29 


18 


125 


3 


47 


Function 


85 


405 


262 


31 


18 


125 


3 


47 


Tracking & 


239 


730 


374 


64 


50 


192 


7 


7 


Ranging 


433 


954 


439 


71 


50 


192 


7 


7 


Ballistics 


234 


552 


420 


28 


20 


170 


18 


16 


Calculations 


518 


793 


467 


29 


20 


170 


18 


16 


Sensor I/O & 


233 


198 


98 


11 


87 


103 


17 


16 


Steering 


343 


330 


132 


14 


87 


103 


17 


16 



Table VI. 13 Summary of A6-E 
Program Segments 
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Bow one of each program segment expresses the rumfcer 
cf instructions in the most time consuming execution 
sequence, that is, the worst case executicr time. Row two 
contains the total number of instructions in the four 
categories. We use these values to estimate worst case 
execution times and memory requirements fcr program and 
data. from the number of variables used externally to the 
subprogram, we can estimate the worst case time requirements 
fcr data transfers on the bus. 

We present the A6-E in sufficient level of detail so 
that we can extrapolate from this data the functional 
requirements for other aircraft, in particular, the VSTOL. 
Because the A6-E is a functioning system, it dees represent 
a real system rather than a hypothetical one. If the 
armaments and sensors of the VSTOL are functionally the 
same, then we can expect close similarity in the operational 
flight program. 

A few points about the nature cf the A6-E program 
might be made. There is a large number cf branch statements 
in relation to arithmetic statements. On the average, one 
third of all statements are branch (IF) statements in the 
FORTRAN implementation. More than half of the statements 
are control statements (IF, GO) . This indicates that the 
control complexity is very high and hence testing the system 
is difficult. The ratio of FORTRAN statements to bytes of 
machine language program is 1 to 8. This is fairly tjpical 
cf higher level languages, although scientific programs 
would have mere code generated from one FORTRAN instruction. 
Another noted fact is that the maximal time execution 
seguence contains approximately 70% of the instructions in 
the entire program. The actual assembly language program 
contains 25% mere instructions than the assembly language 
programs which contain floating point operations. This 
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difference is explained partially cy notice that scaled 
arithmetic operations need a large number of shift 
operations. Also logical operations such as masking 
operations were neglected in the floating point version of 
the assembly language program. 

5. The A7-E Tactical System 

The A7-E computer system is functionally very 
similar to the A6-E. Although the computer, the ASN91 
(TP-2) is different, its capability is nearly the same both 
in terms of maximum memory capacity ( 1 6 K ) and execution 
speeds. The word size is 16 bits, instead of 32, although 
double precision operations exist. 

The sensors for navigation are functionally the 
same, the tracking radar is functionally similar, the 
ordnance and weaponry overlaps to a large extent. The major 
difference is that one man functions both as the pilct and 
navigatcr/bcmbardier . The display is quite different in 
appearance, although from the point cf view cf an 
operational computer program the differences are minor. 

The programming for the operational program was 
designed and carried cut by different pecple, hence a 
different analysis and different numerical methods were used 
to solve the same problems. We did not carry out the same 
analysis for the A7-E as we did for the A6-E because cf the 
lack cf resources. We would not be surprised to find 
considerable differences in the number cf instructions to 
carry out the ballistics function. Two studies have shown 
that equivalent results are attained by pregrams which are 
much shorter [6], [14] and integrate the differential 
equations directly rather than using polynomial 
approximation s. The functional complexity is nevertheless 
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similar in terms of executior. time. 



3. OVERVIEW OF THE FIGHTEE AIBCRAFT F-15 AND F-18 



Figure VI.B.1 depicts the F-15 tactical system's 
organisation. A network consisting of the IBM API mission 
fiocessoi surrounded by 9 microprocessors, each dedicated to 
a particular suttask. The netwcrx is connected together by 
the 1553 time multiplexed data bus. The mission computer is 
very similar to the PI-4 computer in architecture. The add 
and multiply speeds are twice as fast and the divide speed 
is four times faster than the PI-4 computer's. There is no 
floating pcirt option. 

The F-1£ tactical system is shown in Figure VI. £.2 
Ihe two mission computers, AN/UYK-14's, are surrounded by 12 
micrcprocesscrs, each with its own special function. The 
1553 bus again is used to interface the netwcrk. 
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Both ,ths dual bus and the dual mission computers are 
there for redundancy and graceful degradation. The bus 
control function is handled by one or the ether of the two 
mission computers. 



C . 



OVEEVIEK OE THE P3-C ANE S3-A SUSTEMS 



The function of both aircraft is quite different from 
the attack and fighter aircraft. The P3-C is a land based 
aircraft which is primarily used for patrol duty. It is a 
large aircraft, can accommodate a large crew as well as a 
heavy payload of expendable passive or active sonobouys, 
together with ordnance for attacking submarines. 

Its mission is to navigate to its patrol position, drop 
the sensors which relay acoustic signals to the aircraft for 
processing, attack on command, and return to base. Its 
advantage is that it can stay on station for a long period 
of time: its disadvantage is that it is landbased and 
relatively slew. 

Ihe P3-C tactical system consists of a CP901 computer, 
supported by a drum auxiliary memory. The computer has a 30 
tit word length, typically uses 48K werds of memory 
expandable tc 65K. Its execution speeds are in the 5-20 
microsecond range. The drum expands its auxiliary memory 
size to almost 400K words. 



Its most current software system, P3-C UPDATE II, uses 
dual-redundant inertial navigational sensors, Doppler radar, 
and the Cmega radio navigation system in order to determine 
its geographic position. During the tactical phase of its 
mission it navigates with respect to the buoy field. The 
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computer can be used tc release tne buoys at the rignt 
instant tc drop intc a predesignated position. Thus the 
ballistics function is carried by the computer. 

The signal processing details are classified ard not 
included in the report. The stores management function is 
carried out by this computer as well. Except for the signal 
processing function, the P3-C carries out the very same 
functions as the A6-E. Functionally this "core" process is 
very similar. 

Currently the P3-C system is execution time tound. 
Eecause the entire program cannot reside in memory, programs 
must be brought in from the drum, executed, data used for 
ether processes, the program overlaid by another and sc on. 
The operating system must therefore be acre complex and a 
substantial amount of system's overhead arises because of 
the limited memory size and the overload on the central 
processor . 



The S3-A is very similar in its functions to the E3-C. 
Eecause of its smallness, it can land on carriers. The 
smallness, however, limits its time on target, limits its 
crew to four and its payload. Because of its faster speed 
and shipboard base it can make up for some of the 
disadvantages . 



The tactical system consists of 
processor. In its maximum configuration 
bit words of memory. The dual 
configuration is used for both processing 
degradation. Floating point hardware is 
its capability and architecture it is 
AN/UYK-7 . 



a dual UNIVAC 1832 
it can have 256K 32 
central processor 
speed and graceful 
implemented and in 
identical tc the 
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E. THE FUNCTIONAL RE CUIRE M E NTS OF THE VSTCI TACTICAL 
SYSTEM 



1 • _VSTC L fight er -a tta ck ve rsio n 

The functional requirements for VSTCL fighter- attack 
version are assumed to be similar to A-6E, A7-E, F15, F18. 

The sensors are likely to include the presently usee ones 
for navigation and target tracking. Ihe major additions 
will be in the engine monitor-control and landing or takeoff 
flight ccntrcl. There will be unforseen new sensor and 
effector development wich results in a need for designing 
growth capability into the system. 

We shall use the A6-E program actual data as an 
estimate of the needs for these functions which are similar. 
Table VI.D.1 gives cur estimate based on the data derived 
from the A6-E. This is compared to an estimate given in a 
Naval Weapons Center Report. Our estimates are 

somewhat lower, under the assumption that memory 
requirements for programs and data will not differ 
substantially from present values whatever computer is used 
for the implementation. 

The comparison to Naval Weapon Center's estimate 
does not include their 25% safety margin, which brings their 
total estimate to 163,000 bytes of memory. 



Cur estimate amounts to a little mere than twice the 
memory presently used in the A6-E. Of course, only time 
will tell whose estimate is closer to the value used. In 
distributed systems design it is not 
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Program Marne 


Memory Requirement 


Estimates 




A6-E Program or 
Estimate 


NWC 

Estimate 


Executive 


7600 


7200 


Navigation 


2716 


9400 


Air to Surface 


6620 


7100 


Air to Air 


2800 


4600 


Data Link 


2500 


2260 


Target Tracking 
Multiple Targets 


7042 


9000 


Displays and 
Data Entry 


10,000 


25,900 


Engine Management 


10,000 


16,000 


Flight Control 


8,000 


- 


Unforseen 25% 


10,000 


20,365 


Total 


71,598 


101,825 



Table vi . D . 1 Estimates of Program and 
Data Length in Bytes (8 bits) for VSTOL (Attack Version) 
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crucial that the estimate be correct tc the 
module. If mere processing is needed anothe 
its own memory can be added. In case of 
computer, it is more important to leave 
expansion, because exceeding the available 
size causes serious difficulties in systems 
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2. _V5 1C L ASH Version 



Tc make an estimate of the functional requirements 
fer the ASW version is somewhat more difficult. If the 
sensors will be similar to P3-C and S3-A then the major 
differences will exist in the display processing. We are 
assuming that the number of personnell carried by the 
aircraft will be less than or egual to the S3-A. 
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We have not seen any program complexity estimates 
version of VSTCL. Our estimates rely heavily cn the 
d S3-A present implementations. The execution rates 
uncticnal segments vary and some are considerably 
cr ASW applications than are fighter or attack 
. The operating systems in current implementations 
complicated because a large part cf the operational 
resides an drum and is brought into the computer's 
cnly when priorities permit. Therefore, the use of 
tional segments which exist in the P3-C and S3-A 
and whicn are implementation dependent do net allow 
eject into the future with the same accuracy as for 
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the attack/fighter versions. 



Program Name 


Memory Requirement Estimates 


Executive 


10,000 


Navigation 


7,000 


Tactical Control 


20,000 


Communications 


4,000 


Tracking and 
Sensor Management 


8,000 


Displays and 
Data Entry 


20,000 


Engine Management 


10,000 


Flight Control 


8,000 


Signal Processing 


80,000 


Unforseen 25% 


41,750 


Total 


208,750 


Table VI. d. 2 


Estimates of Program and Data 



Length in Bytes (8 bits) for VSTOL ASW Version 
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VII 



SYSTEMS IMPLEMENTATION 



In this chapter we assume that the applications pregrams 
have been designed, decisions on which computers to use have 
been made and the interconnection scheme has teen 
determined. We shall look at alternative implementations 
from the pcint of view that the same application pregrams 
must be executed on the system with the same update 
frequency and with a numerical accuracy which is nor 
degraded by the computational system. Although our study 
concerns itself with the future systems and therefore the 
computer systems cf the early 1980's would be the ones used 
tc implement the systems, we shall use presently available 
computers xo demonstrate the feasibility cf constructing 
homogeneous distributed systems from present-day technclcgy. 
Again, LSI computers of the 1980's will simply mean fewer 
chips in the network compared tc present estimates. 

A. HOMOGENEOUS IMPLEMENTATION 



1 • Jhe Systems Hardware 



Ihe 


system 


is built from 


identical 


sin 


gle 


beard 


processors 


such 


as the INTEL 


SBC80-2C 


or 


th€ 


Texas 


Instruments 


TM 9900 


. The boards are 


connected 


by 


the 


INTEL 



MULTIBUS, II TILINE or the Digital Equipment's UNIBUS. A 
group of single board computers connected cn a parallel bus 
is called an affinity group [4], as shewn in Figure VII. A. 1. 
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Affinity Group 1 



Sensors 




Figure VII. A. 1 
Board Computers in 



Two Affinity Groups of N Single 
a Homogeneous Distributed System 



137 






Ehysical remoteness of system's elements makes a 
parallel connection expensive and inconvenient. Therefore, 
the physically remote system's elements are connected ty a 
serial bus, such as the MLSTD 1553 A/B bus, with either 
twisted pair or a fiberoptic connector as the physical 
device which provides the interface. The present maximum 
data rates on the parallel bus are 40-50 megabits/seccnd, 
whereas 1 megabit/sec is the present standard maximum rate 
for MLS 1 C 1553. In a typical conf ig uraticn the system has 
dual serial fusses to provide redundancy and single parallel 
fusses tc provide lccal service. The Texas Instruments 
study [4] refers to these bus structures as global and lccal 
tus structures. 



Ther 

he mcgenecus 
example, we 
presentl y 
consider enh 
floating pc 
consider sea 
with a sixte 

In c 

number, we 
an enhanced 
1SI-11 each 



e are a number of alt 
architectures to con 
could use the presently 
available single board 
anced systems by adding 
int hardware to the sy 
led arithmetic and float 
en bit mantissa. 

rder to keep the alternati 
consider cnly the INTEL 8 
floating point arithmetic 
with a floating point unit 



ernatives 


even 


struct systems. 


available 


chip 


computers. 


We 


presently 


a va 



stems. We coul 



ing 


pcint 


ar it 


ves 


at a 


reas 


080 E 


(the E 


stan 


unit) 


, the 


TI 



c 



c 

il 

c 

tm 



cn 



cs 

S 



with 

For 

and 

culd 

able 

also 

etic 



able 

for 

S00, 



2 • Distri buted S yst ems Design 
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explicitly identifies the input and output data and control 
variables. Ihe input variables must be available tc the 
process before the execution starts. 

If a single computer is used tc carry out the 
processes, as is the case with A6-E, then each process is 
executed in a predefined sequence. If a process is not 
needed, its execution is bypassed. Figure VII. A. 2 shows 
the time-line of the processes for one execution of the A6-E 
cperaticnal flight program. The worst case execution 
sequence is less than .2 seconds for the entire pregram. 
There is a period of idle time before the next iteration is 
carried cut. 

Each process is a function which operates on a set 
cf input values and generates a set of output values. In 
the language of Chapter V the function may be described as a 
data flowgraph. The number of output values which are used 
elsewhere in the pregram can be identified as vertices of 
the flowgraph which connect the data flcwgraphs of the 
corresponding processes. Figure VII. A 3 illustrates the 
idea using hypothetical data flowgraphs. 
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Figure VII. A. 2 Time Line for the Single Computer 
A6-E Execution Sequence 




Figure VI I. A. 3 Data Flowgraphs for Three 
Hypothetical Processes 
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The same computational process can he carried cut by 
a collection cf slower processors. As an example, let us 
pretend that the processors we wish to use are approximately 
three times slower than the single processor which 
successfully is able to carry out the three processes. If 
computers 1,2, and 3 are assigned to processes 1,2, and 3, 
then their execution times become three times longer, as 
shown in figure 



Computer 1 
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2 sec 
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3t 



i-1 
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Computer 3 

t— ■■ ■■ ■ 



,i-2 



.i-1 



3t 



i-2 



3 1 



i-1 



3t. 



Figure VII. A. 4 Time Lines for a Three 
Computer Implementation of the Distributed System 



V II A . 4 Each computer is able to complete its process in 
the .2 second interval. If the processes are completely 
independent, then the i-th iteration can be carried out 
simultaneously and no difference would be observable between 
the single computer solution or the three computer solution. 
If the processes use each other's results as indicated in 
figure VIIA.2.2., then the iteration rate would remain less 
than .2 second but the dependent values would be delayed by 
three iterations. It is therefore important that the 
partitioning process identify the time critical data 
flowgraphs and place them into the either the same computer 
cr the same iteration interval. 
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Another aspect which becomes important is the 
transfer cf data between computers. The parallel data bus 
allows several fcrms of data transfer at high transfer 
rates. The use of common memory for these data values which 
need to be transferred between computers is particularly 
efficient whenever relatively few such values are to be 
placed on the system bus. Computers would interfere with 
each other cnly when two computers simultaneously wish to 
access the common memory. 

Other methods of message transfer, which reguire 
simultaneous attention from the transmitting and receiving 
computers, would give rise to more message transfer 
overhead. However, the maximum data transfer rates cf 40-50 
megabits per second on the system bus make the data transfer 
overhead almost negligible as seen from the calculations 
which follow. 

1c establish that such a system cf single beard 
computers can successfully solve the tactical problem, we 
first lock at the A6-E program, which is analysed in 
complete detail, and the summary information is given in 
Table V.l. lhe worst case execution time estimates to carry 
cut each cf the processes at the rate of five repetitions 
per second is tabulated. 

If we chose to carry out the A6-E process using 
three computers, one choice is to assign the navigational 
function tc one computer, ballistic calculations, 
input/output, and steering calculations to another, tracking 
and ranging, and senscr calculations to a third. This 
assignment would tend to minimize the bus traffic because 
the number of data items tc oe transferred from the 
navigational computer is 47 floating pcint guantities and 3 
logical variables. The ballistics computer would need to 
communicate 16 floating point and 18 logical variables. The 
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tracking, ranging, sensor, input/output, and steering 
computer will need to communicate 24 floating point and 23 
logical variables. Since these variables are communicated 5 
times per second, the total number of bits per second is 

(44 + 37 * 4) *8*5= 15,68C 



If the communication takes place at the maximun rate 
cf 4G,00C,00C bits per second,, the total data communications 
time is .39 milliseconds every second. Added to this would 
be the time required tc service and set up two interrupts 
from each of three computers five times per second, which as 
a maximum cf 30 interrupt services per seccnd. Interrupt 
service times are at worst about 50 microseconds per 
interrupt. This would add 1.5 milliseconds to the data 
transfer times. If the common memory ccncept is used for 
data transfers then each memory access requires an 
additional system bus access cycle of 200-300 nanoseconds, 
which would add a total of 

(44 + 87 * 4) * 5 * 2 / 5 = 784 

to the executioE time every second. Therefore, a three 
computer system would in the worst case use .15% of the bus 
capacity. The total estimated execution times in seconds 
fcr each computer including communication time is listed in 
lanle VII. A. 5. 





8080 E 


LSI-11 


TI 9900 


Computer 1 
Navigation 


.2786 


.2685 


.267 


Computer 2 
Ballistics & 


.3916 

I/O 


.370 


.363 


Computer 3 


.683 


.660 


.653 



Track & Range 

Table VII. A. 1 Total Estimated Worst Case Execution 
Times (Per Second) for the A6-E System 
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Application Functional Data Operating 



Program 


Subprograms 


Unique 


Dupl System 


Total 


Computer 1 
Navigation 


2.2 K 


1 K 


.6 K 


.2 K 2 K 


6 K 


Computer 2 
Ballistics I/O 


6.6 K 


1 K 


.9 K 


.IK 2 K 


10. 6K 


Computer 3 
Track & Range 


3.5 K 


1 K 


1.2 K 


.IK 2 K 


12 . 8K 


Totals 


17.3 K 


3 K 


2.7 K 


.4 K 6 K 


29 .4K 


Table 


VII .2 


Amount of Memory Required (Bytes) 





For the Distributed System 

Computer 3 is used most heavily at about 66-68% 
capacity. The difference between the performance estimates 
cf the three LSI computers is almost negligible. This is 
due to the fact that the most time consuming operations are 
the floating point operations. The floating point unit 
performance is nearly the same for all three computers. 
Distributed systems' implementation using private memory 
requires that certain programs exist in each computer 
namely, the programs required for data transfers, the 
functional subprograms (SI, CO, CN, AT, SQ) , and some 
input-output handlers. If the systems use private memory, 
then the data items shared by the computers will be copied 
from one memory to another and in the worst case three 
copies of the shared data will occur. 

The estimated number cf bytes of memory required for 
the programs is assumed to be nearly the same in all three 
LSI computers. We estimate the program length in the PI-4 
computer to be nearly the same as in the LSI computers 
because cf the similarity in architectures. The estimated 
memcry requiremens for the distributed system is given in 
Iable VII-3. We have tabulated in Table VII. 3 a 
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three computer arcnitecture in which memory is only shared 
for common data values. Consequently, functional 
subroutines, some data and the operating systems are 
duplicated in each computer. This architecture has the 
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capability provided by the prsent-day single beard LSI 
computers will be available cn the single chip by 1985. The 
present computational requirements for the A6-E will 
therefore be satisfied by a single board cn which three 
single chip computers provide the computational capability 
and the remaining chips are used to interface the system to 
sensors and displays. The cost, weight and power 
reguiremens cf such a system will be a small fractions of 
their present values. We are net naive tc believe that the 
computational reguiremens will remain fixed. We expect that 
increased capability of the chips will encourage an increase 
in computational requirements. We believe that the most 
cost-effective soluticn to these problems is a distributed 
system of these chips which are most widely used and hence 
sell at a cost closest to the recurring production costs 
which are measured in dollars per chip. 

3 . The D is trib ut ed Hom oge n eous S_yste mj_s Implementat io n 
Cf VSTOL 
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Ke wish to estimate the number of single beard 
computers needed to implement the VSTCI systems using 
presently available LSI computers. Because the 7ST0L 
aircraft will be comparable in performance tc the S3-A and 
P3-C, the present iteration rates for the processes are 
assumed to be sufficient. Because the presently used 
computers are in the best case ten times faster than the 
currently available LSI single board computers, certairly no 
more than ten computers are necessary to give the same 
iteration rate as the present systems. Therefore, the basic 
issue in trying tc estimate how many single board computers 
are needed becomes the question of memory size. 

At this time the single beard computer which 
contains the most memory has 8K bytes of program memory and 
2K bytes of BAM. Six months frem now both of these numbers 
will almost certainly double because 16K bit chips are 
already on the market. Therefore, with present technology 
10 single beard computers connected by a parallel bus into a 
system which contains a commcn memory for the variables 
needed tc be shared is an upper bound estimate. This would 
allow us tc build a system with a total cf 116K bytes of 
memory which is well above the estimated 102K bytes stated 
as an estimated requirement by Naval Weapons Center [2C] for 
VSTOL attack version. 

It is superfluous to stare that within a year the 
system's memory size could be 200K bytes and as cur 
estimates indicate, this system in 1985 will be composed of 
10 chips on a board instead of 10 boards in a card cage. 

4 • Software I ssue s of Distr ibuted S ys tems 

In the previous segment we have outlined a method to 
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use existing single board LSI computers to construct a 
system which solves a tactical problem of the complexity 
which occurs on the A6-E. In order to bring such systems 
into existence, a program must be generated. In most 
airborne applications, the program development, testing and 
maintenance costs have been paid for each new airplane. 
Typically, the major airframe contractor assumes the 
responsibility for the computer program. Closely related 
functional aircra f t , ( A-6E A-7E),(P3-C, S3A) , have different 
computers connected to similar sensors, displays and 
weapons. In the past, programs were written in assembly 
language to make program size small and execution time as 
short as possible. The programming effort was repeated for 
each new project. The human-intensive programming effort 
has teen expensive in the past and is continuing at the same 
level. The decreasing hardware costs encourage greater use 
of computers, hence more programming of nearly the some cost 
per instruction. Therefore, not surprisingly, the software 
cost to hardware cost ratio is approaching £0/20 and likely 
tc continue its growth. 

Ecth users of computers and computer manufacturers 
recognized early that it is tc both of their advantage to 
make the lifetime of programs as long as possible. The 
development cf higher level languages (FORTRAN, COBOL, ALGOL 
etc.) net cnly increased the productivity cf programmers, 
but also allowed the programs tc be transferred frem cne 
computer to another, from cne generation tc another. When 
disk systems replaced tape oriented systems, many cf the 
programs did not survive intact. They had tc be 
substantially rewritten in order to make efficient use of 
the system. 

In airborne applications, the computer systems have 
always teen operating near their capacities both in speed 
and memory size. The peripherals: the sensors, displays 
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and effectors have not teen interfaced to the computers with 
standard interfaces. [therefore, much cf the program will 
have tc change, whenever changes are made ir. the 
peripherals. Furthermore, the real time tactical systems 
are characterized by program control complexity which is 
much greater than programs of similar size in ether 
applications. Therefore, the testing of programs becomes a 
lengthy and complex task which is subject tc change whenever 
the peripherals change. The combined effect of all the 
causes is that not much effective transfer cf programming 
effort has taken place from one project tc another. Orly in 
systems updates, such as P3-C Update II, has there teen 
substantial saving of reprogram aing effort. 

Ihe present Navy policy is to try to enforce the use 
of both the standard higher level languages: CMS-2, SEI-1 
as well as standard computers. It is hoped that enforcing 
these standards will make the lifetime of tactical programs 
longer than one generation, as well as allow transfers of 
programs between projects. The use of standard airborne 
computers, namely the AN/UYK-20 compatible AN/UYK-14 is 
helpful in both hardware maintenance and ability tc use 
program development tocls, such as compilers, assemblers, 
etc. which have been already developed for the AN/UYK-20. 

This policy on the surface appears to enable the 
saving of the large investment in the stockpile of computer 
programs which the Navy has generated fer its tactical 
systems. Examination shows that this policy alone is not 
sufficient tc allow tactical programs tc be carried frem on 
generaticn tc tne other. Whenever the systems architecture 
changes, or changes in the sensors or displays occur, cnly a 
minor portion of the programming effort would carry over to 
the new system. For example, the introduction of the phased 
array radar into a system, would not only change the sensory 
interface but the entire tactical system because radically 
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new information with different accurac 
information transfer rates becomes availab 
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Successful preservation of software from one 
generation cf computers to another has been accomplished in 
these applications which are processor configuration 
independent. By expressing the program in a higher level 
language such as FORTRAN, it becomes useable on any computer 
which has a FORTRAN compiler. The FORTRAN compiler itself 
can be made more easily transferable from one generation to 
another if the so-called "intermediate code" emitted by the 
compiler is general enough sc that the cnly change necessary 
tc adapt the compiler to a new computer is the rewriting of 
the final phase of the compiler, namely the "code emitter". 
The scientific subroutine packages, compilers, assemblers, 
editors, and ether programs which only depend on general 
purpose input-output devices are examples cf programs which 
have been successfully preserved from generation to 
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generation. 



Ihe present Navy policy to force the contractors to 
use the "Navy standard airborne" computer AN/UYK-14 has the 
following consequences 

1) It creates a narrow branch of "Navy standard 
airborne" computers and thus prevents the Navy's 
participation in the "LSI revolution" of radical cost 
reductions in hardware and software by the use of def acto 
"industry standards," the DEC'S LSI-11, INIEI's 8080E, II's 
1MS9900. 



2) It tends to create heterogeneous systems 
consisting of the "Navy standard AN/UYK-14's" surrounded by 
a variety of different "industry standard" microprocessors. 
Ihe F-18 and F-15 designs are good examples. 

3) It will net solve the problem of preserving the 
applications software from one generation to the next for 
the reasons mentioned in the previous pages. 

4) It will allow the CES-2M compiler to generate 
code for the AM/UYK-14 and thus the expense of rewriting the 
compiler would be saved. 

At this time we cannot cite successful single beard 
distributed systems designs. Much of this design work is 
presently going on and reports are yet to be written. From 
cur own experience, the design and static testing of 
applications modules is the most time consuming effort. 
Very accurate predictions of maximum execution times can be 
obtained by writing and executing the programs on existing 
developmental systems. Most of program development can be 
accomplished conveniently on systems which are specifically 
designed for program development. Existing timesharing 
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Ihe decisions cf which particula 
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virtually the last minute. Decisions of 
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time when sufficient performance data for 
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Ihe dynamic testing of the modules which belcnc to a 
single board computer can then be done with using in circuit 
emulation systems. (INTEL’S in circuit emulator, ICE, is 
one example of such systems provided by the manufacturer to 
permit the monitoring and final debugging of a system which 
directly interfaces with peripheral circuits.) Each 
computer can be tested independently to check whether cr not 
the predicted performance corresponds to the "in circuit" 
performance . 

Software tools to monitor the interaction of several 
computers on a data bus are presently under development by 
the distributed LSI computer manufacturers. These software 
tools at the final integration tests are useful to resolve 
interaction difficulties. 
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recording tae information on the bus would be to dedicate 
cne single beard computer to be the monitor-recorder. Our 
recommendation is to use high level languages which are not 
cnly standard in the Navy but extend to at least the Defense 
Department, preferably beyond. Use of defacto standards, 
namely languages which have become standard because of high 
degree of use are preferable to decreed standards. Our 
r eccmmendaticn is to phase out CMS-2 because it no longer 
offers significant advantages over defacto standards such as 
FORTRAN. With the use of floating point arithmetic, the 
scaled arithmetic which CMS-2 supports is nc longer needed. 
The language BASIC appears to be becoming the defacto 
standard in the LSI computer applications. Ihe LSI 
environment encourages simple, small languages which are 
easy tc learn and require a small memory for 
compiler/in tsrpreter execution. Because distributing the 
computing removes critical execution time problems and the 
inexpensiveness of memcry removes the necessity for being 
parsimonious with memory, higher level languages are 
certainly appropriate for airborne computing. The cnly 
serious drawback of BASIC is that it dees not support 
"structured programming form." The language PASCAL, ELM, 
and some ether "structured languages" may eventually win the 
popularity race for LSI computing. 



£. HETEROGENEOUS IMPLEMENTATION 



The heterogeneous implementation is patterned after the 
F-18 system's concept. A dual "mission" processor is used 
to increase system reliability, supported by a myriad of 
smaller processors each possibly of different arithmetic 
capability. Figure VI. B. 2 describes the implementation 
using that alternative. 
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There is one major reason for heterogeneous systems, 
namely tne feeling that the capability cf " nicrocomp t ters" 
is not sufficient tc carry cut the calculations required of 
an airborne tactical system. The dual system in the F^18 
design is justifiable from the point of view cf reliability. 
If one system malfunctions, the ether continues to operate 
the system in a degraded mode. The sc-called "mission 
computers" are in the "minicomputer" class and may (in case 
cf AN/UYK-14) or may not (in case of P— 15) be constructed 
from LSI chips. 



There is a 
architecture. The 
have experience 
which is used to 
subcontractors wo 
microcomputers . U 
cause redesign a 
point has nc ex 
systems. There i 
especially if the 
immediate action, 
minicomputer, much 
contracts. If t 
the "mission" comp 



strong pull towards thi 
subcontractors who prov 



and knowledge 


or 


one mic 


make their 


sensor "sm 


uld naturally 


be 


at tra 


se of a "sta 


ndard" mic 


nd a higher pr 


ice. 


The c 


perience with 


horaegene 


s considerable 


risk from 


time pressure 


of 


the c 


Therefore, 


the 


centra 


like the cnes 


he 


has u 


he program ha 


s to 


be doc 


uter must already 


have a 



s form of systems 
ids the sensers 
rccomputer system 
art." Different 
cted to different 
rccomputer would 
cntractor at this 
cus- distributed 
his point of view 
cntract requires 
ctcrs choice is a 
sed in previous 
umented in CMS-2, 
CMS-2 compiler. 



152 



Hence, even if a contractor would be alls to generate a 
homogeneous distributed system of LSI computers as the least 
cost solution, someone would have to provide a CMS-2 
compiler, which by itself would cost an estimated $4-9 
million to develop [3]. He has no choice other than the 
heterogeneous system. 

Minimization of aquisition costs tends to create a 
heterogeneous system. As noted earlier, the subcontractors 
who are not using the Navy "standard" microcomputer would 
have to redesign their systems. This would result in higher 
aguisiticn ccsts. 

The major penalty of heterogeneous systems for the Navy 
comes after the system has been aguired. The documentation 
af several different microcomputers, together with different 
assembly languages, or special microcomputer higher level 
languages will cause educational problems for the 
personnell. The cost will be proportional tc the numter of 
distinct microcomputer systems present. 

Spare parts which allow on line system's servicing will 
grow in number in proportion to the number af distinct types 
cf computers. 

He will ncte that if the system is erxcrfree and if the 
mean time between failures reaches 100,000 hours, as 
discussed in the next segment, then the maintenance 
penalties for the heterogeneous systems are in total value 
small compared to the total life cycle cost cf the system. 
Cnly experience will demonstrate this. 



C. COMMUNICATIONS PROTOCOLS 
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The communications protocols are dependent on the bus 
structure. Typically the protocol is stratified to several 
levels. At level zero is the hardware protocol which is 
usually different for different manufacturers. There are 
seme standards which are of importance (IEEE 448,CAMAC) 

At level 1 is software support provided by the manufacturer 
so that the user does not need tc concern himself with 
developing software. Typically the manufacturer also 
provides subroutines at level 2 which enable the user to 
carry out data set transfers, process synchronization etc. 
At level 3 are usually higher level language subroutines 
written in FORTRAN, BASIC, PASCAL, etc., which permit the 
applications programmer to make higher level language 
statements which cause data transfers to target subsystems. 
The applications programmer does not need tc know any mere 
detail than hew tc use the subroutine. There are attempts 
tc standardize the protocols even at this level. At level 
feur are the global operating systems (if any) . For 
heterogeneous systems such developments would depend on the 
system's configuration, which computers are used and hew 
they are configured. For a homogeneous system, such 
operating systems are provided by the systems's 
manufacturer. (INTEL'S RMX 8C Real Time Executive system.) 
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kernel of such an executive. The user builds a customized 



for 



level of 


software cn tep 


of 


the kernel 


sy stems , 


the development 


costs of e 


tactical 


applications 


has 


been enti 


fcidely u 


S€x LSI homogeneous 


systems 


costs w 


ill be measured 


in 


thousands 


millions 


cf dollars used 


to 


develop op 



154 



VIII. 



COMPARISON OF REL IABI LITY OF THE DESIGNS 



A. MOST LIKELY ERRORS AND FAULTS 



The experience with LSI chips dates tack only a few 
years and therefore statistical data about reliability as a 
function of time is not yet complete. Accelerated life 
testing data is available only on seme systems. The 
commercial version of the INTEL single beard computer SBC 
80/10 has undergone reliability analysis. The accelerated 
life test reported in £11] gives the mean time between 
failures (MTEF) as 91,739 hours at 90% confidence. If the 
equipment is operated 24 hours per day at 25°C then the 
expected life of the system is 10 years. This corresponds 
clcsely to field data, which indicates an MTBF of 90,845 
heurs. Operating the system at higher temperatures, 55°C, 
reduces the MTBF to an extrapolated 25,000 hours. The 
single board computers which are made up of military 
standard components have net been studied. Higher 
reliability would be expected fer these computers. 

In airborne systems, the sensors, radio communications 
equipment, displays and other peripherals, and pewer 
supplies are currently the least reliable systems 
components. A reliability improvement in the computer part 
of system by an order of magnitude will exaggerate this 
problem. Therefore, reliability improvements to the total 
system are not likely to arise noticeably by increasing the 
reliability cf the computer portion, although distributed 
computer architecture will give the systems designer 
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opportunities to do this. The observed mean time between 
failure of all sensory instruments and displays for the F-4E 
was 48.7 hours (UEDPS, 66-1 Field Data) Page 64, [9]. 
Therefore, a system using LSI technology will fail so 
infrequently in comparison to the peripheral instruments 
that the well known Maytag television commercial, in which 
the serviceman complains because he has nc trouble calls, 
will indeed be the case. 

E. TESTABILITY 

Testing for malfunctions in a single computer system is 
done initially before takeoff. Thereafter, if the computer 
fails in flight, the operator may again invoke the test 
routines. Typically the computer is tcc busy tc do 
self checking . 

In a distributed system the time pressure is net as 
great and selfchecking can be incorporated into the periodic 
execution sequence. In a system which is homogeneous, only 
cne test program needs to be written. In a heterogeneous 
system each distinct processor needs its cwn test pregram. 
In a distributed system external checking may be 
accomplished. In erder for a computer to dc self checking , 
it needs to be functioning to some degree. An external 
computer can be effective in testing after selftesting is no 
lenger feasible. Again homogeneous systems have an 
advantage over heter egenoeous systems. Distributed systems 
have an advantage over single computer systems. 

C. DIAGNOSIS OF ERRORS 
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A single computer system is usually under such 
timepressure that it can afford to do very little in 
diagnosing errors. Cnly minimal error diagnostics are 
typically implemented in such systems. In a distributed 
system, the timepressure is less critical, hence mere 
sophisticated error diagnosis can be done. We generally 
wish to protect ourselves against the most likely sources of 
errors, namely the sensors. If independent measurements 
using different instruments agree with each other, we 
usually can trust the results. If there is disagreement, 
then we look for inconsistencies, large changes in small 
time intervals, etc. Small biases in instruments are 
particularly difficult to diagnose. However, with digital 
systems, ealitratien problems are easier tc solve because it 
is possible to record information over time periods anc make 
small adjustments. For example, if a digital watch is off 
one second a day consistently, then if we have access tc the 
count which determines the displayed unit of time we can 
alter that and correct the bias. Distributed systems have a 
advantage and homogeneous distributed systems have a added 
advantage because of uniformity. 

D. EEECE TCLEBANT FUNCTIONING COSING MISSIONS 



The present systems implementations have already a large 
degree of error tolerance. In the A6-E and A7-E the 
navigational instruments can gradually fail. There are 
typically four modes of navigation: inertial-Eoppler , 
inertial alone, Doppler alone, air data alone. However, if 
the computer malfunctions, then only manual backups remain. 
In a distributed system there are many options for the 
designer. For example, there may be a spare computer which 
can be activated and which either has in its memory pregrams 
for the vital functions or can read the program intc its 
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memory from an auxiliary memory. 



Another solution would be to have the vital functions in 
two computers so that if one fails, the ether can carry on, 
much like a pilot and copilot function on transport 
aircraft . 



E. GRACEFUL DEGRADATION 



Graceful Degradation refers precisely to the concept 
that one or more failures in the system degrade the 
performance tut do net totally cause the system to collapse. 
A distributed system, particularly if it uses optical 
interfaces between components, has the ability to degrade 
gracefully. If systems elements are connected 
electronically they are not as well isolated and a serious 
failure in a system connected to the bus can cause a failure 
on the bus, which makes the entire system inoperable. An 
optical bus is not nearly as vulnerable because of the light 
signal isolates the systems electronically. 

A systems designer has many options to create a system 
whose total failure is very unlikely. Duplicating or 
triplicating systems elements would be an obvious way. 
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IX. ECONOMIC ANALYSIS 



A. SUm .’ARY OF ECONOMIC ANALYSIS METHOD 

When estimating the costs of alternative engineering 
implementations using a still emerging technology, like large 
scale integrated circuitry, performing the economic analysis 
begins by making projections into the future about a set of 
significant variables. In the case of LSI, some of these 
would be propagation delay, gate/chip, cost/gate, failure rate, 
cost/connection, etc. There in fact exist several of these 
significant variables that could be identified, each one 
having a point, and an interval estimate of their value fore- 
cast at certain steps along the future time line being con- 
sidered. An exhaustive analysis would seek to take all possible 
combinations of all possible values of the variables to measure 
the costs and uncertainties in those costs of the alternative 
engineering implementations. This type of analysis can quickly 
lose any intuition it might have built for a decision maker 
in a mass of data points. 

An alternative approach, and the one selected for this 
report, is to first create a set of broad risk categories 
that relate to the problem being analyzed, and to generate 
from them scenarios each with a neutral (or most likely) , a 
slightly optimistic, and a slightly pessimistic case. The 
outcome of these three cases is a set of three values for 
certain key variables. The cost of the alternative engineer- 
ing implementations is then based on this outcome. What 
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this narrative scenario approach accomplishes for a decision 
maker is a projection into the future structured around some 
managerially meaningful categories. The constants across 
the scenarios are the competing engineering implementation 
philosophies and the risk category structure. In structuring 
the scenarios it is important to free the implementation 
alternatives from the risk categories to be able to see how 
they then stand against each other across a spectrum of risk. 

A decision maker can then see how each competing alternative 
would fare cost-wise in possible futures that have more mean- 
ing than might be drawn out of a mass of data points. 

For the economic analysis of this report alternative 
avionics computer architectures, each embodying LSI technology, 
will be placed in the context of two possible scenarios devel- 
oped on the milestone path of the VSTOL aircraft. Each scen- 
ario structures the risk inherent in the future into four 
broad categories. The first category will be called the 
semiconductor industry as related to technological changes in 
and the marketing of microcomputing devices. The second cate- 
gory is the systems acquisition strategy for future avionics 
in light of OMB circular A109 and with regard to source 
selection and contract incentive structure. The third cate- 
gory is the maintenance-manpower system which entails repair- 
discard, level of maintenance, and labor mix possibilities. 

The last category, aircraft employment, addresses not only 
the number of VSTOL aircraft projected as a base for operating 
and support costing and the rate of aircraft production, but 
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also their method of employment, i.e., from which ship types 
they will be operated and maintained. The implication of the 
last category is that ship types capable of VSTOL flight 
operations may not be capable of complete maintenance or of 
multi-mission operational support. 

The two scenarios will follow a baseline description of 
the VSTOL program and the four risk categories. The baseline 
develops the necessary background for structuring the two 
scenarios and their neutral (most likely) , slightly optimistic, 
and slightly pessimistic cases. This economic analysis pro- 
cess is pictured in Figure 9-1. 
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ECONOMIC ANALYSIS METHOD 
F igure 9 - 1 



B. 



BASELINE 



As stated, the four categories of risk briefly are, the 
semiconductor industry, the systems acquisition strategy, 
the maintenance-manpower system, and the employment 
possibilities . 

1. The Semiconductor Industry as Related to Technological 

Advance and Marketing of Microcomputing Devices 

The first chapter of this report generalized the impact 
of large scale circuit integration on computing technology. 

A more detailed account with particular reference to techno- 
logical change and marketing of microcomputing devices will 
be discussed here. 

The primary effect on the market of LSI has been to open 
up new applications areas for microcomputing devices. In 
particular, is the opening up of three areas that can be 
broadly classed as the process control market, the consumer 
market, and the small business or hobbyist general purpose 
personal computer market. The thread common to all of these 
markets is the implementation of what was previously electro- 
mechanical analog logic and/or custom designed electronic 
circuitry by general purpose digital computing logic inte- 
grated to one or a few semiconductor chips. 

Before briefly reviewing the history of these microcom- 
puting devices, reflection on the life cycle of computer 
products in general reveals a reasonably standard sequence 
of events. Technological advance in circuitry design occurs 
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first, followed by exploitation in the form of a product made 
possible by improvements in manufacturing technology. The 
product, if accepted in the market, begins to find further 
applications. It is gradually enhanced in performance to 
meet these new found applications, creating a family of com- 
puters. Peripheral equipment and software development tools are 
developed by the parent company. If the product really makes 
an impact in the market, like the DEC PDP8 did in terms of 
helping to create the minicomputer market, other companies 
specializing in peripherals, maintenance, or software support 
and applications spring up. The basic product is upgraded 
until it is no longer economic, and then emulated as transi- 
tion to a replacement computer product occurs. 

With this in mind, concentrating on the traditional Von 
Neumann building blocks of the digital computer, the processor, 
the memory, the input/output, and the timing circuitry provides 
a framework for describing the technological change-marketing 
paths that have appeared to date and that are projected to 
appear in the two scenarios of this report for LSI computing 
devices . 

A semiconductor company, Intel Corporation, already a pro- 
ducer of LSI memories was the strongest initiator in the 
microprocess er/microcompu ter device market . Their Intel 4004, 
a four-bit word length device, was the first commercially 
successful microprocessor. It was and is used in limited 
scope process control and some consumer products like pong 
games. As a designer's tool it required a read only memory 
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chip to provide space for the controlling program. Timing 
circuits, and input/output interface devices were also 
required. As more circuitry could be put on a chip because 
of semiconductor manufacturing technology improvements, the 
question presumably became for Intel, "For commercial success, 
should all the building blocks of a digital computer be placed 
on one chip or should the single chip processor be made more 
capable in terms of word length, processing speed and instruc- 
tion set?" Empirically the evidence shows that the processor 
was made more powerful first, with the introduction of the 
Intel 8008, an 8-bit word length processor, and then with the 
most commercially successful microprocessor to date, the 
Intel 8080. Several other microprocessors entered the market, 
of course, the AMD 2900, the Motorola 6800, the Zilog Z-80, 
the LSIll, and now the 16-bit Texas Instruments TI9900, to 
name a few. The significance of the last three examples named 
is that they are enhancements over the 8080 and that they 
came prior to the Intel 8048 family, the first complete com- 
puter-on-a-chip on the market and also prior to the TI9940, 
also a computer-on-a-chip. Also of significance is the fact 
that Intel announced the 8085, a fifty percent speed enhance- 
ment of the 8080 at the same time as the 8048 family. 

Several reasons can be postulated as being behind this 
technological change-marketing path. The first is that semi- 
conductor read only memory chips to hold the applications 
program were already available from separate vendors. 

Another is that when a process control is designed in the 
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framework of digital computing logic it is done so with the 
traditional Von Neumann computer building blocks in mind. 

The process is first described by the design engineer in terms 
of data flow, i.e., input signals being transformed by func- 
tional operators into output signals. The job is then sized 
in terms of execution times and memory space as separate 
constraints. The result is separate implementation. As 
applications are worked out using digital computing logic, 
memory size can be incremented by adding memory chips in much 
the same way that memory is added to a general purpose main 
frame or minicomputer as applications are developed. Now that 
the use of single and few chip microprocessors has made its 
initial impact on the applications market, the computer-on- 
a-chip with its fixed resident read only memory fits the 
applications that are becoming more defined in the literature 
as to execution time, memory size, and instruction set 
manipulation. 

Restated another way, the microprocessor impacted the 
market, the market in turn then impacted the microprocessor 
development path. As a company makes technological headway 
as did Intel with the first microprocessors, that technology 
is exploited for the payback to the investment as outlined by 
the S • N £ CNR + CR • N formula of the early chapters in this 
report. After the first device hits the market the strategy 
generally is to follow with performance enhancement as the 
users become more familiar with the implementation. As other 
companies come into the market with even faster performing 
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then 



devices as did Zilog, DEC, Texas Instruments, et al. , 
the lead company, in this case Intel, generally begins to dis- 
criminate its product line by the support system, and then by 
some technological leap-frog that is intended to put distance 
between itself and the others. The last few paragraphs de- 
scribe some of the several reasons, besides those of semicon- 
ductor manufacturing technology, that most probably were behind 
the chronology of introduction of the Intel 804S single chip 
computer, i.e., after the enhancements to the original suc- 
cessful microprocessors. 

One other aspect of the market that bears mentioning is 
the development in the licensing of a product's technology 
(a concept pointed out in the Computer Family Architecture 
report, referred to in the next section, as most probably 
holding the key to much of the cost differential in most actual 
negotiated product selections) . In the earlier days of com- 
puting, and to this day, IBM held near and dear to its tech- 
nological secrets as it gained its dominant position in the 
market. Now companies will license the use of trade secrets 
to competitors. The most relevant examples are the license 
agreement Norden, a division of United Technologies, has with 
Digital Equipment Corporation to produce the military versions 
of the PDP/LSIll's, the ROLM license with Data General Nova 
Division, and recently the AMD license agreement with Intel 
to use Intel design masks to produce 8080A's. Two other 
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important ones stand out. The first is to obtain a quick 
return for the parent company on a technological implementa- 
tion in a high rate of technological change area in the face 
£ 

of the 10 dollar development cost for the device, referred 
to early in this report. The second is to increase the base 
of use of a product both in number of devices and number of 
sources and hence gain a wider acceptance of the product as 
an industry standard. 

In summary, a major point in this technological change- 
marketing path baseline is the development of the understand- 
ing that the applications market has an influence on the 
technological form of a product along with the physical laws 
governing the shape of that product and the manufacturing 
technologies that produce it. What the scenarios will try 
to structure then from this risk category is two possible con- 
tinuations of the established trends so as to be able to 
structure the available technology packages and their support 
systems for VSTOL avionics with a probable baseline freeze 
of 1985. 
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2. The Systems Acquisition Strategy 

The previous risk category primarily addressed the pro- 
ducers. This category addresses the user side. The thrust 
from users in any high technology area is to somehow create 
a set of standards so as to minimize repetitious investment 
in capital equipment and cost of ownership. A buffer of 
standardization is created to protect the user from the 
rapid pace of technological change. 

Currently several different movements amongst the users 
of computing devices exist. First, within the military 
services, the Military Computer Family Architecture (CFA) 
committee has established an analysis which outlines what a 
military computer family requirement would be with regard to 
a standard instruction set and software support and then goes 
on to show with sound argument that the commercial PDPll 
commercial family satisfies the requirement. 

Within the Navy the Assistant Secretaries of the Navy for 
Installations and Logistics and for Research and Development 
have sent out a joint memo dated 30 March 1977 for comment, 
mapping out a short term and long term strategy to cope with 
the proliferation of computing devices. This memo establishes 
for the near term the continuation of the UYK7 and 20 in the 
surface Navy as the standard computer family, and the AYK14 , 
a machine made in bit slice fashion from the LSI AMD 2900's 
and compatible with the UYK 20, as the Naval airborne interim 
standard. It calls for all future microcomputer/microprocessor 
acquisitions to be of devices capable of implementing these 
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respective instruction sets. In the longer term it calls for 
evaluation of the CFA proposal in light of the competing 
AYK14, UYK7 and 20 interim standards. 

The AYK14 currently has possible homes in several Navy 
airborne projects (9-1) . 



Project AYK14 1 s 



F18 1600 

LAMPS III 205 

AV8B 350 

IEWS 300 

TACOMJAM 80 

HARM (Avionics) 361 

TASSES 24 

WIDEBAND DUAL MODE 1000 

URAIDS VARIABLE 

DIFAR 350 

CAINS IA 1000 

LINK 11 285 

PROTEUS 500 



6255* 



*while not exact or official, these numbers are representative. 



Most significant are the F/A-18 which will have two AYKl4's 
together on a mil standard 1553 type bus, the LAMPS Mk III 
helo which will have one AYK14, the P3C Update III which may 
have an AYK14 in network to offload the at~capacity central 
computer, and the AV8B , the advanced Harrier for the Marine 
Corps. The importance of these projects will be seen in the 
scenarios. With the exception of LAMPS Mk III, the final 
direction of each of these projects is not yet firm as of 
this writing. The ultimate outcome of each of these projects 
is in some measure tied in with the VSTOL concept. Any one 
of a number of outcomes could occur, affecting the ultimate 
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base number of AYKl4's in the Navy system. This will be a 
key factor in costing out the alternative computer architectures 
in this report via the scenario — neutral, optimistic, pessimis- 
tic case idea. That number, along with the following totals 
for existing airborne computers in the Navy, has considerable 
meaning when reflected on in light of the S • N £ CNR + CR *N equa- 
tion inherent in LSI computing device development expressed 
earlier in this report (9-1) . 



Type of 
aircraft 


Number of computers 
per aircraft 


Number of 
aircraft 


Total number 
of computers 


E2C 


3 


36 


108 


AID 


1 


400 


400 


A6E 


1 


200 


200 


S3A 


5 


165 


825 


P3C 


1 


150 


150 


F14 


6 


200 


1200 








2883* 



*while not exact or official, these numbers are representative. 

The connection of the VSTOL project with the National Aero- 
nautics and Space Administration also has significance in terms 
of the possible acquisition strategies which might come to pass. 
In the absence of a general aviation standardization committee, 
like the kind ARINC provides for commercial aviation, NASA has 
taken it on itself to provide such a forum. In late 1977, it 
will initiate a Request for Proposal (RFP) for a general avia- 
tion computer based avionics demonstrator with award to be 
made in mid 1978 and delivery to occur in 1980-81 for evalua- 
tion. Currently postulated answers to the RFP based on prelim- 
inary NASA work indicate a. multiple computer network on a 
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bus like mil standard 1553A or IEEE 483, with a multifunction 
display--not dissimilar with the F18/F15 solutions and the 
homogeneous alternative of this report. Form, fit, and func- 
tion standardization is being sought to allow for advances 
in technology much like ARINC standards for commercial avia- 
tion. Although the environment for a general aviation air- 
craft may not be exactly the same as for VSTOL (although 
corporate type jets are in use by the Coast Guard and reach, 
in commercial use, the edge of the speed and maneuverability 
envelopes of their military sub-sonic counterparts) , the 
degree if any to which the NASA effort links with the VSTOL 
effort could influence the cost of the implementation alter- 
natives. This effect will be addressed in the scenarios. 

Even if the actual hardware is somewhat different, the concept 
of implementation and the interface standards might extend 
across general aviation and military applications. 

Another very significant point in the acquisition strategy 
revolves around OMB circular A109. This systems acquisition 
circular among other things requires that early attention of 
industry be invited by a statement of mission needs vice 
specific hardware specifications in the RFP . The impact of 
this is that concept definition and validation are essentially 
obtained via industry participation with specific hardware 
implementation not delineated. Prior to OMB A109 a definite 
piece of hardware and consequently its inherent technological 
implementation became locked, very early in the acquisition 
process, into detailed specifications. In interviews with 
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airframe manufacturers and Navy software support activities, 
much of the "software cost problem" is viewed as really a prob- 
lem of correct software but for a hardware specification over- 
come by the events of technological change and the resultant 
specification changes. 

A position of this study made apparent by its very nature 
and more specific in the scenarios, is that if the Navy lab 
structure, i.e., the labs and their research arms in college 
campuses, private think tanks, and public institutions are 
considered as "industry," a wider definition of A109, without 
losing its spirit and intent, opens up a number of possible 
acquisition strategies. As pointed out by this report, the 
nature of the aircraft avionics problem and its digital com- 
puter implementation is such that very basic and useful work 
can be done via the Navy lab structure on the problem in terms 
of data flow, control flow, higher order language, coding of 
algorithms, architectural considerations and life cycle cost 
modeling. 

If one first abstracts across several aircraft, as is done 
in this report, a set of mathematical structures relating the 
flow of data is obtainable. By doing this a core (navigation, 
ballistics, etc.) is obtained that would be common to all the 
mission variants of an aircraft like VSTOL. Each aircraft 
begins with that core and adds to it the mission variants. 
Beginning with that idea the process can be pictured as 
emanating from the center of concentric circles (Figure 9-2). 
Eventually the implementation of these functions occurs. In 
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CONCENTRIC VIEW OF VSTOL COMPUTATION REQUIREMENTS 

Figure 9-2 



the past in planes like the F4 it was in analog fashion. 

Now these mathematical structures are implemented by digital 
computing logic. This core would establish the way in which 
the mission variants and particularly what are called the 
embedded processing elements would interface, both initially 
and then across time as the system grew to meet added 
requirements . 

The significance of this appears when, from empirical 
evidence, it is seen that the aircraft industry is organized 
by airframe manufacturers, engine makers, and various avionics 
and electrical shops that relate to specific mission variants 
or avionics functions. There are flight control shops, radar 
shops, electronic warfare shops, weapon systems shops, etc. 

Each shop as technology users will be exploiting LSI technol- 
ogy and replacing large amounts of circuitry by microprocessors 
and read only memory, in what is called embedded fashion, in 
their own piece of equipment. By going back to the concentric 
circles it can be seen that several different approaches to 
acquisition can be taken. The avionics shops, airframe and 
engine manufacturers, can be allowed to de facto decide what 
the core looks like by impinging toward the center of the con- 
centric array from the outside. Or the user can define the 
core first as ARINC does for the commercial aviation world, 
and allow the circles to grow outward in an orderly fashion 
from the central core. Looking closely at commercial aviation, 
ARINC, a third party created by mutual consent of the airlines 
defines this core and an orderly fashion for interfacing to it. 
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NASA is now attempting to do this for general aviation. If 
the VSTOL project managers are thought of as the users, then 
the Navy lab structure could be viewed as the third party in 
the acquisition strategy to define that core. Note that this 
does not mean definition in terms of specific hardware, on 
the contrary it would be in more abstract terms of control 
and data flow, execution times, memory requirements, bus 
interface protocols, HOL algorithms, etc. This would structure 
then how the mission variants of the plane and embedded pro- 
cessing elements would interface with each other and the core. 
As with ARINC, this would be free of hardware implementation 
and allow technological change to be captured up to the point 
of baseline freeze. What the scenarios and their neutral, 
optimistic, and pessimistic cases will do is hypothesize 
possible acquisition paths and see how the cost of the two 
architectural implementations of this report would be affected. 

3. Maintenance-Manpower System 

In an economic analysis it is generally intended that the 
fallout of the analysis is the repair-discard, level of 
maintenance, and labor mix results. However it is often the 
case that organizational inertias or organizational optimiza- 
tion of other criteria than the economics of competing 
engineering alternatives prevail over the analysis results. 

This risk category therefore lays out some considerations that 
are later structured into possible outcomes in the scenarios. 

As exhibited in articles in the electronic engineering 
trade journals, there is concern over job description because 
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of the fact that electrical circuit implementation is becoming 
in many areas, particularly process control, one of digital 
computing logic. The emotions attached to this can be expressed 
by the quote of one aerospace industry engineering head who 
stated emphatically that he didn't have any computer program- 
mers, he had aerospace engineers that were called upon to 
program. The trade magazines such as Digital Design, Elec- 
tronics, Spectrum, etc., have begun to run articles that 
address the electronic engineers' outlook with respect to this 
microprocessor/microcomputer phenomenon . 

The relationship to the Navy maintenance-manpower system 
becomes visible through the viewing of businesses that are 
recognizing that their very organizational structures are being 
impacted by LSI technology in digital computing logic form. 

The separation between the computer science departments and 
the other engineering design departments is being obscured as 
the electronic engineers are being required to know digital 
computing logic and programming, and vice versa. Although 
the Navy maintenance-manpower system is a user vice designer 
system, a knowledge of the implementation of circuitry by 
digital computing logic is a requirement for understanding 
its maintenance. It is reasonable to expect that just as the 
electronics engineer design trades are impacted by LSI tech- 
nology, so will the maintenance trades. 

The meaning of this to the Navy is simply, or not so 
simply, NEC and rating restructuring. The not so simply comes 
in the sense that a maintenance-manpower system is not created 
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overnight. Just as the el2ctronics engineer is concerned 
with his educational preparation and the protection of this 
human capital investment in the face of LSI digi- 
tal computing technology, so will the maintenance man. LSI 
digital computing technology might dictate via economic 
analysis that a solution to the maintenance-manpower system 
structure be one group of people that understands built-in- 
test design and operation at the organizational level of 
maintenance, another that understands circuit board logic 
testing at the intermediate level of maintenance, and those 
that understand digital computer program design, analysis and 
troubleshooting at the depot level. Restructuring NEC's and 
ratings to accomplish this, independent of whether the system 
is in an airplane, a ship, or a submarine, cannot be done 
instantaneously. It may not even be recognized as a positive 
goal by the manpower-personnel planning systems since the 
separation of maintenance ratings by warfare specialty creates 
other positive intra- and inter-organizational relationships. 
The scenario method is used therefore to address the possible 
relations of LSI to the maintenance-manpower system and the 
costing fallout, vice assuming the normative case. 

Existing evidence that there is recognition of the possible 
effect of LSI on the maintenance-manpower system is the joint 
service symposium on Automatic-Test-Equipment held in June 
1977. Each service presented its programs in the area, sol- 
iciting inputs from industry as well. Some possible relevant 
developments that could occur out of this tri-service program 
will be considered in the scenarios. 
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Another aspect of maintenance of no small significance 
is the software development and support of the digital compu- 
ting logic applications software. There is more than one way 
to develop and support the software. If the aircraft avionics 
hardware and applications software procurement is bundled, 
support of that software could come from that source. If the 
procurement is unbundled, a software vendor or avionics shop 
could provide it. The Naval Air Systems Command has created 
its own applications software support activities in the Naval 
Air Development Center at Warminster, Pa., the Missile Test 
Center at Point Mugu, California, and the Naval Weapons Center, 
China Lake. They handle the operational flight programs (OFP) 
for the ASW, high performance fighter, and attack aircraft 
respectively. The current thrust is to pass to these software 
support activities control of the applications software after 
a certain point of testing in development. This task becomes 
more difficult as the use of digital computing logic imple- 
mentation and its required software spreads throughout the 
aircraft in the form of microcomputer/microprocessor based 
systems. 

The impact addressed in the scenarios is the effect in 
terms of the type of software development and support systems that 
might be decided upon as outlined in the generalization 
of cost issues in this report. 

4 . Employment 

The VSTOL aircraft as with the LAMPS , and its drone pre- 
decessor the DASH, is more closely intertwined with the parent 
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ship that supports it operationally and for maintenance. The 
question of how much processing and display equipment the ship 
and aircraft should host respectively is heightened in the 
case of VSTOL because of the take-off gross weight restrictions 
of the VSTOL technology. Any discussion of VSTOL ultimately 
becomes a discussion of the Navy surface ship force structure, 
again no simple discussion. 

Currently the Navy force structure is debated around three 
force levels, a 400, 500, and 600 ship Navy; and two force 
mixes, sea control and power projection. To understand the two 
mixes one must first understand the two most basic roles of 
the Navy. The first is the projection of strike power inland 
as embodied in the strike carrier task forces and the nuclear 
strike cruisers. The second is the control of the sea lanes 
as embodied in the smaller escort vessels and the hypothesized 
sea control ship now called the VSS or VSTOL support ship, 
about the size of the Amphibious Assault Helicopter Carrier 
(LPH) . Alternative force structures were developed by this 
author from Navy testimony in Congress, a National Security 
Council study, and two Congressional Budget Office working 
papers . 

The outcome of these alternative forces goes into providing 
the base number of VSTOL aircraft that could reasonably be 
expected to exist in the 1991-2001 time frame and hence the 
number of airborne computers. The maintenance structures that 
could reasonably be expected to exist were also developed from 
these alternative force structures. 
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C. SCENARIO (AIRBORNE STANDARD) 



This scenario is meant to be interpreted in the metaphori- 
cal sense. Its intent is to relate events in time so as to 
establish how, most likely, slightly optimistic and slightly pessi- 
mistic cases might be generated from a collection of realistic events . 

The scenario begins in the fall of 1977. The Naval Post- 
graduate School's report on distributed LSI microcomputing 
for VSTOL avionics has been received with interest. It is 
read in several places which include the Naval Air Systems 
Command Avionics and Software Support Offices (NAVAIR 533), 
the VSTOL Program Office (PMA 269) , and as an input to the 
ASN IL/RD memo of March 1977. In November of 1977 the VSTOL 
RFP for conceptual studies goes out. The NASA RFP for the 
general aviation computer based, multiplexed bus, and multi- 
function display demonstration also goes out at about the 
same time. 

In December of 1977 Norden, a division of United Technolo- 
gies, makes first deliveries of the LSI11M, a military version 
of the DEC LSI 11, announced in the summer of 1977 as an 
embedded use companion for their PDP11/34M. The military 
Computer Family Architecture committee which recommended the 
PDPll family for the military form, fit, and function specifi- 
cation uses this to add emphasis to their analysis. The 
LSI11M instruction set is a subset of the PDP11/34M, would be 
compatible for embedded use in a bused network with the PDPll 
family, and uses the existing PDP11/DEC family software 
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development and support systems available from a multitude of 
commercial sources and already in place in many military 
activities . 

Intel Corporation's commercial success with the 8080 
microprocessor family continues. The 8080 family as enhanced 
in the summer of 1977 by the speed improvements (a factor of 
2) of the 8085 is marketed as the ad hoc industrial process 
control and consumer market standard. This marketing position 
is furthered in the fall of 1977 by the licensing and second 
sourcing of the 8080 family by National Semiconductor and 
AMD in the form of chip sets families and single board compu- 
ters. Other successful entrants in the microprocessor/micro- 
computer market in terms of accumulated experience (devices 
sold) are the Motorola 6800, an 8-bit word length microprocessor, 
and the Texas Instruments 9900, a 16-bit word length micro- 
processor, all single or two chip microprocessors which also 
provide the base for those companies' single board microcomputers. 

From the fall of 1977 to mid 1979 when the RFP for VSTOL 
avionics advanced development (concept definition and valida- 
tion) is made, the technological-marketing path the micropro- 
cessor/microcomputer industry has taken is one of exploitation 
of circuit integration at the level of the classical computer 
building blocks of processor, memory, input/output, and timing 
devices. Memory technology in particular progresses on paths 
different than semiconductor processor technologies so that 
magnetic-bubble, floppy disc, and holigraphic memory forms 
provide alternatives for implementation, particularly for 
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random access mass or block memory. Because of systems 
designers' desire for flexible memory size, the single chip 
semiconductor computer in mid 1979 has not become the dominant 
industry implementation for process control, the consumer 
market, or the general purpose microcomputer. 

The single chip semiconductor computer is however a limited 
commercial success by mid 1979 at the 4, 8 and 16-bit word 
length with a resident memory capacity of 4K words ROM and 
a rated throughput of 0.5 million instructions per second. 

By 1985 it is anticipated that the single chip computer will 
have replaced the microprocessor plus separate read only mem- 
ory chip as the implementation for process control and the 
consumer market at the 8 and 16-bit word length with a resi- 
dent memory capacity of 16K words ROM and a rated throughput 
of 1 million instructions per second. It will not however be 
the primary implementation for the general purpose microcom- 
puter. Intel, Motorola and Texas Instruments remain the 
dominant forces in these markets and their 8080/8048, 6800, 
and 9900/9940's the dominant families. 

The ASN IL/RD in mid 1978 accepts with minor modification 
the mid term and long term strategy indicated in their memo 
of 30 March 1977. The Computer Family Architecture committee 
with the growing use of the LSIllM receives endorsement of the 
PDPll family in mid 1978 as the basis for a military computer 
family. The AYK14 and UYK7 and 20 programs receive a DOD 
variance endorsement however to proceed in parallel, as already 
established, for their respective Navy shipboard and airborne 
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communities. A further evaluation point for the ASN IL/RD 
memo is set for mid 1979. This timing coincides with the 
RFP for VSTOL advanced development (validation and definition) . 

The structure of the Navy shipbuilding program is coalesc- 
ing with the President's budget for FY8 0, moving in the 
direction of a 500 ship Navy. Thirty-two ships will be capa- 
ble of landing and launching VSTOL aircraft. The avionics 
conceptual studies proposals, replies, and awards show general 
agreement that the following ship types, CV, CVN , and VSS 
(LPH size ship), are under review as organizational and inter- 
mediate level maintenance and multi-mission operations 
platforms. The strike cruiser CGSN is under consideration for 
single-mission operations and organizational level support. 

The maintenance strategy is generally being conceived as one 
of built-in-test (BIT) monitoring and line replaceable units 
(LRU) removal and replacement at the organizational level with 
the discard or repair of modules decisions made at the inter- 
mediate level of maintenance, and further repair made at the 
depot level. LRU size is accepted as measured in ATR (ARINC 
air transport racks) dimensions with modules measured in 
Standard Electronic Modules (SEM2A) which are increments of 
ATR 1 s . 

The defense budget being formulated in mid 1979 for FY81, 
funds completely the F/A-18 program production. The implica- 
tion of this is that the AYK14 will have a permanent home in 
the Navy fighter/attack aircraft inventory with 800 F18's 
programmed for by 1990 and about 100 F18's programmed to be 
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off the production line by early 1980. Additionally, the P3C 
Update III is to be implemented by an AYK14 networked with the 
existing central processor on a mil standard 1553 type bus. 
Both of these decisions are in keeping with the near term 
strategy of the ASN IL/RD memo. The AV8B Harrier is dropped 
however in favor of the A4M and F/A-18, and the coming VSTOL 
program. 

The mid 1979 reevaluation point for the ASN IL/RD memo is 
faced with three complications. First, the CFA committee 
findings opting for the PDPll family is solidly backed by 
that families continued commercial success, particularly the 
LSIll subset. Second, the growing AYK14 program has created 
a significant investment in that family. Third, the micro- 
processors plus memory chips and single chip microcomputer 
have proliferated in embedded use in weapons and tactical 
systems even in the face of the March 1977 memo. The prolif- 
eration is at the point that several types already exist in 
the Navy inventory supporting such diverse tactical and weap- 
ons system implementations as tactical aircraft landing gear 
retraction. Marine Corps electronic battlefield devices, and 
guidance devices for remotely piloted vehicles. A non- 
exhaustive list of these types are the AMD2900, LSIllM, the 
Intel 8080, 8085, 8048, 8748, the Motorola 6800 's and the 
TI 9900, 9940's. The implication here is the proliferation 
of their respective software development and support systems 
and interfacing requirements. Also complicating the issues 
laid out in the memo and its mid 1979 reevaluation, is the 
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inconclusive nature of the direction taken by the automobile 
industry from the fall of 1977 to mid 1979. Although expected 
to be very large quantity users and hence prime movers in the 
standardization of the microprocessor/microcomputer industry, 
the competition between the big three and also between their 
respective model divisions in terms of exploiting the LSI 
microcomputer/microprocessor technology has held up this 
standardization. An ad hoc standardization has occurred with- 
in model divisions. This standardization is on the basis of 
an 8-bit word length (with the exception of Chrysler) by late 
1978 and then on the Motorola 6800 at Ford, the Intel 8080 at 
GM, and the TI 9900 at Chrysler as their respective standard 
instruction sets by mid 1979. An IEEE 488 multiplex bus and 
its protocols and interface standards are in the concept stage 
for production implementation by the 1983-1985 model year time 
frame. 

The importance of the automobile industries' position with 
respect to the military is in the fact that the temperature 
range faced by electronic circuitry in the environment of the 
automobile engine is a sustained -75°C to +450 o C (9-2),300°C 
more than that required by mil specs for LSI/IC's. Hence, 
the automobile industry as a potential 10 million unit per 
year user of microprocessor/microcomputer based process con- 
trol systems could by the volume of their use remove the extra 
factor of 2 to 3 the military currently pays for its micro- 
processor/microcomputer devices. Additionally, the automobile 
makers could create the instruction set, interface, bus and 



186 



protocol, and power standards in volume which general aviation 
and the military could accept as their own. 

The NASA contract for a demonstration general aviation 
avionics is let in April 78 in answer to the late 1977 RFP . 

By 1980-81 the demonstrator is in operation using a mil stand- 
ard 1553 type of bus, and a distributed network of Intel 8080 
family microprocessors plus ROM chips type of architecture, 
and a multi-function display. 

In light of these events, in particular the growing AYK14 
base, and the influence of the ASN RD/IL memo, the RFP for 
VSTOL advanced development avionics definition and validation 
is structured so as to indicate selection of the LSI bit slice 
AYK14 family as the airborne computer in VSTOL. An additional 
anticipation in mid 1979 from the RFP is that the HSX, and VPX 
would be built from the same AYK14 family as the VSTOL. As 
a minimum then, a NAVAIR standard airborne computer family 
emerges. It is also anticipated that the embedded micropro- 
cessors and single chip computers, even if procured from 
separate sources, be made to conform with the AYK14 standard 
as to word length, instruction set, and interface on a mil 
standard 1553 type bus with either a shielded twisted pair or 
fiber optic implementation. It is further outlined in the 
RFP that this AYK14 family be targetable from the DOD HOL. 

With this in mind, the VSTOL program avionics advanced 
development definition and validation proceeds in early 1980. 

Additional events between 1980 and 1985 affect the results 
of this process. One is the Navy part of the Tri-Service Ad 
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Hoc Automatic Test Equipment Project. It is decided to con- 
tinue with the VAST system concept incorporating the AYK14 
family into it. 

Electronics/avionics technicians, like their commercial 
counterparts, begin to develop skills in the fundamentals of 
digital computing as a part of the recognition by the Naval 
Training Commands of the similarities in engineering/maintain- 
ing microcomputing devices that cross traditional rates and 
equipments. Although no rating consolidations ' take place in 
this 1980-85 time frame, the climate is set and some NEC 
(Navy Enlisted Classification Codes) are consolidated between 
the ET, AT, and DT rates. 

This scenario will be used to cost the two architectural 
alternatives, the heterogeneous with AYR 14 LSI bit slice 
computers in the avionics core networked with AYK14 sub- 
system front end microprocessors, and the homogeneous with a 
distributed network of commercial microcomputers made to meet 
mil specs in both the core and subsystem front ends. Each 
system concept will be assumed developed by an avionics com- 
puter shop during the VSTOL concept validation advanced 
development stage, rather than by the lab structure or the 
VSTOL airframe manufacturer. The most likely or neutral 
case, slightly optimistic, and slightly pessimistic cases of 
this scenario will develop costs around hypothesized annual 
rates of growth of the AYK14 standard family and commercial 
microcomputers . 
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D. SCENARIO (COMPUTER FAMILY ARCHITECTURE STANDARD) 

This scenario is meant to be interpreted in the metaphor- 
ical sense. Its intent is to relate events in time so as to 
establish how most likely, slightly optimistic and slightly 
pessimistic cases might be generated from a collection of 
realistic events. 

The scenario begins in the fall of 1977. The Naval Post- 
graduate School's report on distributed microcomputing for 
VSTOL avionics has been read by the Naval Air Systems Command 
Avionics and Software Support Offices (NAVAIR 533 and NAVAIR 
360), the VSTOL Program Office (PMA 269) , and as an input to 
ASN IL/RD memo of March 1977. Another interested reader is 
the NASA study group working on the RFP (to be released in 
late 1977) for a general aviation computer based, multiplexed 
bus, and multi-function display avionics demonstrator. The 
NASA RFP for the demonstrator and the Navy VSTOL RFP (to be 
released in late fall of 1977) for conceptual studies, although 
independently conceived, are each reciprocally tracked in 
recognition of the similarity of their purpose. 

The Military Computer Family Architecture committee also 
recognizes the similarity of purpose in the NASA and VSTOL 
RFP's. Norden (a division of United Technologies) begins 
delivery of the LSI11M in December 1977, a military version 
of the DEC LSIll, announced in the summer of 1977 as an embedded 
processing companion for the PDP11/34M. The LSIll is a multi- 
chip processor containing a subset of the PDP11/34M instruction 
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set, supported by the same software, and capable of being used 
in embedded fashion and/or in a bused network with the PDP11M 
family. 

The two RFP's and the LSIllM are used as evidence by the 
Military Computer Family Architecture committee to further 
the position of their analyses for a set of form, fit, and 
function specifications around the PDP11/LSI11 family. The 
point made is that this family will capture the existing 
commercially available software development and support sys- 
tems for nor only military applications but also for general 
aviation as well. 

Intel Corporation's commercial success with the 8080 
microprocessor continues. The 8080 family as enhanced in the 
summer of 1977 by the speed improvements (a factor of 2) of 
the 8085 is marketed as the ad hoc industrial process control 
and consumer market standard. This marketing position is 
furthered in the fall of 1977 by another second sourcing of 
the 8080 family by National Semiconductor and AMD in the form 
of single chip processors and single board computer packages. 
Other successful entrants in the microprocessor /microcomputer 
market continue to be the Motorola 6800, and the Texas Instru- 
ments 9900, both single chip microprocessors. 

From the fall of 1977 to mid 1979 when the RFP for the 
VSTOL avionics advanced development (definition and validation) 
is made, the technological change-marketing path the micro- 
processor/microcomputer device industry has taken is one of 
rapid continuation of circuit integration to the point of 
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having all of the classical computer building blocks, processor, 
memory, input/output, and timing devices on one chip in the 
form of the Intel 8048' s, TI 9940's, and a Motorola product as 
yet undesignated. Although alternative memory implementations 
such as the magnetic-bubble, floppy disc, and holigraphic 
forms exist, the single chip MOS implementation dominates them 
by mid 1979, providing more than enough memory flexibility and 
speed for applications designers. Hence, the single chip 
computer becomes the dominant implementation for process con- 
trol, the consumer market, and the general purpose microcompu- 
ter market, replacing the microprocess plus ROM chips arrange- 
ment. By mid 1979 it has an 8-bit or 16-bit word length and 
16K or 8K bytes of ROM respectively and a rated throughput of 
0.5 million instructions per second. By 1985 this has 
increased to an 8-bit or 16-bit word length each with 64K 
bytes ROM and a rated throughput of 1 million instructions per 
second. This single chip computer continues to dominate the 
process control, consumer, and general purpose microcomputer 
market by 1985. In fact, the hand held calculator and general 
purpose microcomputer market has merged because of this by 
1985. It is not uncommon to see from 4 to 16 of these 
computers-on-a-chip, each mounted in separate or stacked chip 
carriers mounted on a reflux soldered ceramic board linked 
with the parent companies bus system by 1985. Motorola, Intel, 
and Texas Instruments are the strongest entrants in this seg- 
ment of the semiconductor industry. 
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The ASN RD/IL in mid 1978 accepts with some important 
modifications, the mid and long term strategy indicated in 
their memo of 30 March 1977. Influenced by the rapidity with 
which heavy industrial process control is being implemented 
by single chip computers, particularly in the automobile 
industry, and also by the success of the PDP11M/LSI11M, the 
strategy endorses the idea of a military computer architecture 
family with the PDP11/LSI11 family as the leading candidates 
but reserves comment on the ultimate long term standard to 
review the progress of the single chip computer. 

Because they are already established, the UYK7 and 20 pro- 
grams receive endorsement for continuation as the interim 
standard for shipboard application. However, when the F18 
program and the AV8B Harrier do not receive the production go 
ahead decision for Fiscal 79 in favor of increased emphasis on 
VSTOL (with the A7/A4M/F14 filling the gap) , the AYK14 loses 
the substantial part of its base as the airborne standard com- 
puter. Because of this, two other major AYK14 programs, the 
P3C Update III and the LAMPS Mk III program, are in doubt as 
to how to proceed. The P3C update does not happen with the 
AYK14 networked to the central computer but rather with a 
redesign of its software, particularly the Omega subroutine. 

A complete internal overhaul of the computing system based on 
a distributed network of elements of the military computer 
family (when selected) is projected as the ultimate solution. 
The LAMPS Mk III project, further along, uses the AYK14 's 
already contracted for at a projected base of about 300. A 
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further evaluation point relevant to the AYK14 for the Naval 
Air Systems Command of the ASN RD/IL memo is not needed 
because of its demise in the F/A-18, AV8B, P3C decisions. 

The mid 1979 RFP for VSTOL therefore is developed without 
reference to the AYK14 and only refers to the desire to 
adhere to elements of the ultimate military computer family 
when selected. 

The structure of the Navy shipbuilding program is coales- 
ing with the President's budget for FY8 0, moving toward a 600 
ship Navy. Seventy ships will be capable of landing and 
launching VSTOL aircraft. All will be capable of multi- 
mission support and organizational and intermediate mainten- 
ance with the exception of the CGSN strike cruiser and the 
DD963H. These two will be capable of single-mission support 
and organizational level maintenance. The return from the 
avionics conceptual studies and tracking of the Automatic Test 
Equipment Tri-Service Project show that advances in built-in- 
test (BIT) will mean preventive maintenance will consist of 
monitoring BIT program indicators and corrective maintenance 
can consist of faulty module (SEM2A size) replacement at the 
organizational level or line replaceable unit (LRU) removal 
of the ATR size, with module discard taking place at either 
organizational or intermediate level. 

The demise of the F/A-18, and AV8B Harrier in favor of 
VSTOL and hence the reduced base of the AYK14, plus the rise 
in use of the PDP11M/LSI11M family has not stemmed by mid 
1979 the proliferation of other microprocessing/microcomputing 
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devices in embedded use in mission oriented and sensor 
equipment. 

The automobile industry has from the fall of 1977 to mid 
1979 followed a decisive path in their use and standardiza- 
tion of microprocessors/microcomputing devices. After an 
initial time of competition between model divisions they have 
responded to the rapid pace of integration of the entire com- 
puter to the chip level so that by mid 1979 they have devel- 
oped form, fit, and function standards based on word length, 
multiplexed bus type and instruction set ty corporation , with Fbrd 
choosing the Motorola 6800 family, GM the Intel 8048 family 
and Chrysler the TI 9940 family. The result is that by mid 
1979 distributed processing demonstrators have been established 
with production units numbering in the millions to go into the 
1981 model year cars. 

The NASA RFP of late 1977 is awarded in April 1978. By 
late 1980, early 1981, the results are in, the TI 9940 based 
family being chosen as the general aviation standard family 
because of its 16-bit word length, wide usage base by Chrysler 
in distributed fashion, and second sourcing. 

The VSTOL validation and concept definition advanced 
development proceeds with the NASA demonstration as an input 
to the core avionics development, particularly in the multi- 
function display area. The Navy lab structure is awarded the 
concept definition and advanced development phase vice an 
avionics shop or the airframe manufacturer. The two leading 
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candidates costed from this scenario are the PDPllM/LSI 11M in 
a heterogeneous network and cither one of the Intel, Motorola, 
or Texas Instruments single chip computer families in a com- 
pletely homogeneous network. (The TI 9940 family will be 
chosen for illustration purposes since it is also hypothesized 
to be chosen by NASA for general aviation.) 
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E. COSTING RESULTS 

Illustrative costing results are generated from the two 
scenarios for each of their three cases — neutral (most likely) , 
slightly optimistic, and slightly pessimistic--for both the 
heterogeneous and homogeneous computer architecture alter- 
natives. Two equations are used in conjunction with the narra- 
tive of the scenarios to determine several of the cost numbers. 
The first equation is the production learning or industry ex- 
perience curve formulation. 

y = ax 13 ( 9-1 ) 

b = log S/log 2 ( 9-2 ) 

where 

t h 

y = unit cost (price) of the x — unit 

a = cost (price) of the initial accumulated quantity, A 
x = total accumulated quantity 

S = % of previous cost (price) that cost (price) drops 
to when accumulated quantity doubles. 

The second equation is the compounded annual rate of growth 
equation used often in the business world to describe alterna- 
tive future product sales outcomes. 

mA = A ( 1+g) T ( 9-3 ) 

where 

m = multiple of the initial accumulated quantity 
A = initial accumulated quantity in units 
g = annual growth rate in percent expressed as a decimal 
T = years to attain the multiple of accumulated quantity 
desired . 
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To be useful, these equations need an estimate for each 
o the parameters. These estimates were generated for this 
rport by the process of constructing the neutral, slightly 
ctimistic, and slightly pessimistic cases of each of the two 
■enarios. Figures ( 9-3) and (9-4 ) show composite, graphic 
^presentations of the use of these equations with representa- 
.ve values from this report. 

The generic work breakdown structure (WBS) of the Tri- 
arvice Tactical Communications office (TRI-TAC) Fort Monmouth, 
ew Jersey, was used to develop life cycle cost elements for 
he costing effort (Figure ( 9-5)). The method used to deter- 
line whether, a cost element was applicable wa s to first assume 
diat the WBS applies to the entire VSTOL aircraft. Then, 
iollowing the logic flow of Figure ( 9-6) from reference (9-3), 
t list of significant, applicable cost elements for each of 
:he alternative architectures under the three cases of the two 
cenarios were considered for their contribution to the VSTOL. 
'reliminary costing results are pictured in Figure ( 9-7). 

Equations ( 9-1) and ( 9-3) were used to determine acqui- 

ition costs for each basic computing unit of the alternative 

rchitectures. Annual rates of product or device growth of use 

r ere chosen as 30% for the slightly pessimistic case, 50% for 

he most likely (neutral) case, and 100% for the slightly op- 

imistic case. Selected examples of why these rates were 

hosen and how the initial accumulated quantity and their unit 

* 

cquisition costs were determined and led to the values in 1985, 
he hypothesized year of comparison, are outlined below. All 
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UNIT ACQUISITION COST (CONSTANT 197 7 $) 
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UNIT ACQUISITION COST (CONSTANT 1977 $) 
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ACCUMULATED QUANTITY AS A FUNCTION OF INITIAL ACCUMULATED QUANTITY (A) 



1.0 Rosea fell and !)< *ve I opmen L 

1.1 Concent and Validation 

1.1.1 Con true ( or 

1.1.2 Cove rnmont 



1.2 Full >. • development (FSD) 

1.2.1 Con *.. rac tor 

1.2. 1.1 Program Management 

1.2. 1.2 Engineering 

1.2. 1.3 Fabication 

1. 2.1.4 Contractor Development Tests (CDT) 

1.2. 1.5 Test Support 

1.2. 1.6 Producibility Engineering and Planning (P 

1 .2.1.7 Data 

1.2. 1.7.1 Engineering Data 

1.2. 1.7. 2 Support Data 
'.2. 1.7. 3 Management Data 

.. . 2 . 1 . 7 . 4 Technical Orders and Manuals 

1.2. 1.8 Peculiar Support and Test Equipment 

1.2. 1.9 Other 

1.2.1.10 General and Administrative 

1.2.1.11 Fee 

1.2.2 Government 

1.2. 2.1 Program Management 

1.2. 2. 2 Test Site Activation 

1.2. 2. 3 Government Tests (DTE/IOTE) 

1.2. 2. 4 Government Furnished Equipment (GFE) 

1 . 2 . 2 . 5 Other 



Source: TRI-TAC 
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Figure 5 * 



2.0 Investment. (Non-Recurr ing ) 

2.1 Contractor 

2.1.1 Program Management 

2.1.2 Producu.bi.lity Engineering and Planning (PEP) 

2.1.3 Initial Production Facilities (IPF) 

2. 1.3.1 Production Engineering 

2 . 1 . 3 . 2 Tooling 

2. 1.3. 3 Industrial Facilities 

2.1.3 . 4 Manufacturing Support Equipment 

2.1.4 Technical Support 

2.1.5 Initial Spares and Repair Parts 

2.1.6 Initial Training 

2.1.6. 1 Training Facilities 

2. 1.6. 2 Training Devices and Equipment 

2. 1.6. 3 Initial Student Training 

2. 1.6. 3.1 Operator Training 

2. 1.6. 3. 2 Maintenance Training 

2. 1.6. 3. 3 Instructor Training 

2.1.7 Data 

2.1.7. 1 Engineering Data 

2. 1.7. 2 Support Data 

2. 1.7. 3 Management Data 

2. 1.7.4 Technical Orders and Manuals 

2.1.8 Leaseholds 

2.1.9 Common Support Equipment 

2.1.10 Peculiar Support and Test Equipment 

2.1.11 Other Non-Recurring Costs 

2.1.12 General and Administrative 

2.1.13 Fee or Profit 



Figure 9 -S’ ( continued) 
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2.2 Government (N'on-Ueeurr ing) 

2.2.1 Program Management 

2.2.2 Initial Training 

2. 2. 2.1 Training Facilities 

2. 2. 2. 2 Training Devices and Equipment 

2. 2. 2. 3 Initial Student Training 

2. 2. 2. 3.1 Operator Training 

2. 2. 2. 3. 2 Maintenance Training 

2. 2. 2. 3. 3 Instructor Training 

2.2.3 Production Acceptance Test and Evaluation (PATE) 
2.2. A Operational Test and Evaluation (OTE) 

2.2.5 Test Site Activation 

2.2.6 Government Furnished Equipment (GFE) 

2.2.7 Other Non-Recurring Investment Costs 



Figure (continued^ 
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3.0 Investment (Recurring) 

3.1 Contractor 

3.1.1 Manufacturing 

3.1.2 Production Material 

3. 1.2.1 Purchased Equipment and Parts 

3. 1.2. 2 Subcontracted Items 

3. 1.2. 3 Other Material 

3.1.3 Sustaining Engineering 

3.1.4 Quality Control and Inspection 

3.1.5 Packaging and Transportation 

3.1.6 Operat ional/Site Activation 

3. 1.6.1 Site Construction 

3. 1.6. 2 Site/Ship/Vehicle Conversion 

3. 1.6. 3 Assembly, Installation and Checkout 

3.1.7 Other Recurring Investment Costs 

3.1.8 General and Administrative Costs 

3.1.9 Fee or Profit 

3.2 Government (Recurring) 

3.2.1 Quality Control and Inspection 

3.2.2 Sustaining Engineering 

3.2.3 Transportation 

3.2.4 Operational/Site Activation 

3.2.4. 1 Site Construction 

3. 2.4. 2 Site/Ship/Vehicle Conversion 

3. 2. 4. 3 Assembly, Installation and Checkout 

3.2.5 Technical Orders and Manuals 

3.2.6 Government Furnished Material 

3.2.7 Other Recurring Cost 



Figure * 3 -% (continued) 
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•1.0 Operating and Support Costs (0&.S) 

4.1 Operations 

4.1.1 Electrical Power 

4.1.2 Special Materials 

4.1.3 Operator Personnel 

4.1.4 Operational Facilities 

4.1.5 Equipment Leaseholds 

4.1.6 Other Operations Costs 

4.2 Logistic Support 

4.2.1 Maintenance 

4.2. 1.1 Personnel 

4. 2. 1.1.1 Organizational Maintenance Personnel 

4. 2. 1.1. 2 Intermediate Maintenance Personnel 

4.2. 1.1.3 Depot Maintenance Personnel 

4. 2. 1.2 Maintenance Facilities 

4. 2. 1.3 Support Equipment Maintenance 

4. 2. 1.4 Contractor Services 

4.2.2 Supply 

4.2.2. 1 Personnel 

4. 2. 2. 1.1 Organizational Supply Personnel 

4. 2. 2. 1.2 Intermediate Supply Personnel 

4. 2. 2. 1.3 Depot Supply Personnel 

4. 2. 2. 2 Supply Facilities 

4. 2. 2. 3 Spare Parts and Repair Material 

4. 2. 2.4 Inventory Administration 

4. 2. 2. 4.1 Inventory Management 

4.2. 2.4. 2 Inventory Holding 

4. 2. 2. 5 Transportation and Packaging 

4.2.3 Other Logistic Support Costs 



Figure 9-S (continued) 
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Remarks 


Sem 2A Product 
Development 


A/C Design 
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Programming 


One Year 

Supply : 


Ins true tors /Students 
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Ten Years , 77S 
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PRELIMINARY RESULTS FOR SELECTEO COST ELEMENTS (MILLIONS OF FY 77$, DISCOUNTED ZERO PERCENT) 



irs are expressed in current dollars. Inflation, the rise 
ie general price level, is assumed to affect all inputs 
,ly. Discounting was done using a zero percent rate. Us- 
:he standard DOD 10% figure would only make the homogeneous 
even more cost-effective. 

To determine the unit acquisition cost of the naval air- 
; standard computers of the heterogeneous alternative 
)85, the number of these computers procured for naval air- 
i systems by 1985 as a first cut was chosen to be about 
) based on the projections of reference (9-1) . Interviews 
members of the military computer industry indicate that 
: industry average experience curve is 85%, i.e. as accum- 
id quantity doubles, acquisition cost to the user comes 
15%. Currently the annual rate of growth in units sold 
le military computer industry is conservatively (slightly 
.raistically) projected at 30% annually (9-4). Using an 
al accumulated quantity of 500 for the naval airborne 
lard (from unofficial procurement plans and industry inter- 
, a 30% and a 50% annual growth rate bracket the afore- 
.oned 6,000 unit base projected for 1985. 

Three things are worthy of note at this point in the devel- 
tt of these and subsequent figures. First, the industry 
rience curve can be interpreted in a negotiated procurement 
■onment as a production (labor) cost learning curve. The 
. airborne standard computer would be in production run on 
:ed price type of contract for costing purposes in the 
frame of this report. Second, the curve represents the 
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unit learning (experience) curve. The cumulative average 
learning curve would lie slightly above the unit learning curve, 
generating an average unit acquisition cost for a purchase in 
quantity slightly above the unit cost curve. 

Finally, note that sustaining engineering is 
included as one of the recurring manufacturing costs that leads 
to the acquisition cost to the user by the computer industry. 

The meaning of this is that new models of the naval airborne 
standard would continue to incorporate innovations in LSI 
technology, bubble memory, etc., as the costs of the naval air- 
borne standard continued to come down. 

Returning to how the total of the unit acquisition costs 
were developed, the number of VSTOL aircraft in the buy was 
estimated at 1,000 from the force structure analysis referred 
to earlier. The heterogeneous architecture calls for two 
naval airborne standard computer units per aircraft for the 
core avionics. 2,000 units would be procured at unit acqui- 
sition cost of $30,000 for a total of $60,000,000 for the VSTOL 
fleet . 

The airborne standard scenario has hypothesized that the 
Naval Air Systems Command would undertake the development of an 
airborne family microprocessor, not a microcomputer since the 
scenario assumed integration of circuitry only to the computer 
building blocks of processor, memory, input/output, and timing 
circuits at the point in time a development decision was hy- 
pothesized. The development program is assumed undertaken be- 
ginning in mid 1979 with the reevaluation point of the 



208 



4SN(RD/IL) memo referred to in the scenario, and completed in 
1980. Based on a nonrecurring development cost of $150 per 
gate and an equivalent gate count of 10,000 for a single 

or a few chip LSI processor made from the military family of 
LSI chips (9-5),the nonrecurring development cost would be about 
$1,500,000. Note that this would be a sunk cost with respect 
to the VSTOL program. The initial accumulated quantity and 
acquisition cost was determined in the following way. Pricing 
two existing military microprocessors, the LSI11M and the AYK30, 
their single quantity price is about $2,500. In lots of 500 
or more there is a 15% reduction in price which would make the 
iii quantity unit price about $2,125. The growth rates for these 
two military microprocessors were estimated for up to the next 
couple of years at 100% annually from interviews. The price in 
quantity of each of these military microprocessors would be 
about $1,500 by 1980, using equations ( 9-1) and (9-3 ), an 
85% curve and the information above. This is assumed used as 
a design-to-cost figure by Nav Air in the airborne standard 
microprocessor development. Based on the $1,500,000 nonrecur- 
ring development cost and the $1,500 design-to-cost figure, 
the developer would need at least an initial quantity order of 
1,000 to at least cover his nonrecurring cost of development 
and make him competitive with the LSI11M/AYK30 products. 

This was chosen as the initial accumulated experience quantity 
available in 1980 after a year's development effort. A modest 
projection of the annual growth rate of microprocessor/micro- 
computer devices annually as an industry is projected at 50% 
for the next several years (9-6). This growth rate was assumed 
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for the naval airborne standard microprocessor in airborne 
systems as the neutral (most likely) case to begin in 1980 
when the device would be ready. 

Based on the hypothesized 1,000 plane VSTOL buy, and 10 
of these airborne standard microprocessor devices per plane 
in the heterogeneous architecture alternative, a unit acquisi- 
tion cost of about $850 was estimated by 1985. Since each 
naval airborne standard microprocessor would need memory 
(16K words), parallel and serial bus interfacing, and a float- 
ing point package to accomplish its task even in embedded use, 
these would have to be costed into the basic processing unit 
since a microprocessor is not capable of doing anything without 
these other items. Using the LSI11M, AYK30, ROLM Corporation 
and other price lists for these components, costing by analogy 
was done with a multiplicative cost factor of about 4 being 
surprisingly consistent across the various companies. This 
would mean for the neutral case, for example, about $3,400 for 
each microcomputing unit at the front end of an avionics sub- 
system. 

Two other costs need to be considered. The first is the 
nonrecurring cost of programming Automatic Test Equipment (ATE) 
like that in the Versatile Avionics Shop Testor (VAST) for the 
printed circuit cards that would be in each piece of computer 
equipment. Although a standard computer is already in exis- 
tence, each application requires a new test program for the 
ATE. The standard airborne computer has on the average 10 
boards, each assumed "complex" under the description of refer- 
ence (9-7) .A 90% comprehensive median (neutral) cost of ATE 
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programming would be $15,000 per board, a total of $150,000 
for the unit in the neutral case. The airborne standard micro- 
processor plus the equipment to make it a microcomputer is 
assumed to be six boards in a Navy Standard Electronic Module 
2A (SEM2A) product. At $3,400 per airborne standard micro- 
computer of six boards that is about $600 per board. Each 
board was assumed moderate in complexity under the description 
of reference (9-7). At 90% comprehensiveness, median (neutral) 
cost for ATE programming of $5,000 a board would be a total of 
$30,000 for the product. 

The last cost reviewed at this point is a recurring in- 
vestment cost, the VSTOL flyaway cost attributed to the comput- 
ing system weight. Reference (S-5)relates that every pound of 
operational systems weight contributes 6-8 lbs. to airframe, 
fuel system, and other supporting systems weight, and that a 
modern fighter aircraft costs out at $500 per pound of flyaway 
costs. This concept applied to the 50 pounds (2 units at 
25 lbs. each) of the standard units versus the 2-4 lbs 

of the homogeneous computing module makes for an order of magni 
tude differential in the flyaway costs attributable to the 
respective computer architecture alternatives. 

The operating and support costs for both the heterogeneous 
and homogeneous alternatives were generated using the TRI-TAC 
Life Cycle Cost Model, and the B-K Dynamics Navy Billet Cost 
Model. The parameters of mean-time-between-failure (MTBF) and 
mean-time-to-repair (MTTR) were taken from existing data on 
comparable units for the airborne and CFA standard computers. 

The values were 2,200 hours MTBF with 20 minutes MTTR at the 
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organizational level of maintenance and two hours MTTR at 
the intermediate level of maintenance. For the airborne 
standard microprocessor, and for the homogeneous microcom- 
puter the most likely, slightly optimistic and slightly pes- 
simistic case idea was used since field reliability data is 
not mature enough. The values chosen were 2 times, 10 times, 
and . 5 times the MTBF of the airborne and CFA standard comput- 
ers. A figure of about 25,000 hours for the AYK30, LSI11M, 
and TI9900 demonstrated in a simulated field environment is the 
figure developed by interview. The same MTTR's were used through- 
out . 

The costing in the CFA scenario for the heterogeneous 
alternative was also based on equations (9-1) and (9-3) . The 
PDP11/34M and LSI11M were used as representative. The number 
of CFA units in use by 1985 was generated by starting with 
annual military computer industry sales employing LSI tech- 
nology being conservatively (slightly pessimistically) esti- 
mated at $100,000,000 for 1977 and $250,000,000 by 1981 (9-4) 

This would be about a 30% growth rate. Reference (9-4) and 
interviews indicate an initial acquisition cost of about $25,000 
for a 1/2 ATR, 16K work memory PDP11/34M and that Norden 
conservatively expects to grow to about $50,000,000 in sales 
annually within five years. Coupled with the initial unit 
acquisition cost of about $25,000, an initial experience base 
of 500 was considered representative. This yields about a 
$12,500,000 nonrecurring development cost if the first run 
amortizes this cost. Although not directly available, this 
development cost figure is representative. With an 85% industry 



212 



experience (learning) curve the average acquisition cost for 
the CFA unit for the VSTOL core avionics of the 1/2 ATR size 
would be about $15,000 in the slightly pessimistic case by 1985. 
With two of these units per aircraft and a 1,000 plane buy, 
the acquisition cost would be about $30,000,000 for these core 
units. The front end processing units would be as indicated in 
the airborne standard scenario with the exception that the 
factor of four would not be applied because of the assumption 
under the CFA scenario that the direction of integration is to 
more rapidly bring all the building blocks of a microcomputer 
into one LSI chip. 

The costs of ATE programming, and flyaway cost attributable 
to the computing units were computed as in the airborne stan- 
dard scenario. 

No software development and support tool costs were costed 
to either scenario’s heterogeneous alternatives. This is best 
casing of these alternatives since interviews have shown that 
in many projects these tools aren't used or require modification 
to suit the input/output structure of the particular application. 

The VSTOL Operational Flight Program development and 
maintenance costs would be a differential cost element. It is 
computed using the technique outlined in the generalization of 
cost issues section of this report. 

The homogeneous equipment acquisition cost is computed 
for each scenario as follows. In the airborne standard the 
architecture would consist of 24 single chip microcomputers in 
the core in two SEM2A sized modules, and 20 single chip micro- 
computers embedded as front end processors in the avionics 
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sub-system, ten boards of two microcomputer chips to a board. 

The airborne standard scenario hypothesizes that integration 
of computer building blocks to a single chip will not be as 
rapid in terms of memory size, processing speed, and input/out- 
put as in the CFA standard scenario. For the CFA scenario, 
integration to single chip computers progresses at a faster 
pace so that only 12 single chip microcomputers in one SEM2A 
sized module is needed in the core, with ten 10 boards of two 
microcomputers each as front end processing units. These num- 
bers are representative in view of the technical information of 
this report. 

The cost per microcomputer chip in either alternative was 
estimated for the most likely case of each scenario to be $5 
by 1985. This was obtained as follows. References (9-6, 9-8) and 
interviews were used to obtain and check dollar sales volumes 
for industrial LSI microprocessor/microcomputer devices. The 
unit prices attached to each dollar sales volume to obtain a 
figure for quantity produced in each year is the Intel 8080A 
unit price for those periods since it was the industry price 
leader. 

1974 $22,000,000 0 $500 each ^ 50,000 units 

1975 50,000,000 @ $100 each a? 500,000 units 

1976 150,000,000 @ $ 25 each S* 6,000,000 units 

Admittedly, this is a rough way to obtain these figures; 

however, they do check with interview sources close enough to 
be representative. Available volume information in units sold 
of microprocessor/microcomputer chip devices is unreliable 
since these numbers are proprietary information. 1976 is 



214 



chosen as the base year of experience. Reference (9-6) predicts 
an annual industry growth rate of 50% for the next several 
years. This was taken as the neutral case. The industry 
experience curve is well known to be 73%, i.e. as industry 
accumulated quantity doubles, cost and price falls by 27%. 

Using the chosen initial experience accumulation of 6,000,000, 
the price at that quantity of $25, and the neutral annual 
growth rate of 50%, equations (9-1 ) and (9-3 ) yield the $5 
device price by 1985. This figure checked with Delphi ques- 
tionnaires and other forms of interview. It also falls in the 
range of total annual industry sales volume of $500,000,000 to 
$1,000,000,000 predicted from references (9-6, 9-8) for these 
devices. A final way in which the feasibility of such mas- 
sive volume checks out, at least in an order of magnitude sense, 
is to consider the possible types of applications for these 
devices. Reference (9-6 )quotes that of some 25,000 potential 
types of applications considered within the realm of single 
chip microcomputer process control, only 10% of them are 
currently in active design. Applications range from automo- 
biles (10 million vehicles annually with 2-3 microcomputers 
per vehicle being the industry strategy to meet the emission 
and mpg standards of the early 1980's), 40 million appliances 
annually (microwave ovens, washer-dryers, TV's, etc.), point- 
of-sale terminals, precision measurement instruments, to arcade 
games, and children's toys (into the 100's of millions annually). 
With automobiles and appliances accounting for nearly 100 
million devices annually, it is reasonable to see the other 
applications accounting for 200-300 million devices annually 
by 1985 as a neutral case. 



215 



These chips must still be placed into a system or product. 
Using the SEM2A size module with two chips per board and the 
reflux solder on ceramic technique described earlier, an es- 
timate of nonrecurring development costs for such a product is 
about $1 / 5C0 , 000 based on industry interviews. Acquisition 
costs for such a product were obtained from interviews, liter- 
ature (9-5) , and checked against available price lists. The 
results indicate that a factor of about 2.5 times the sum of 
the acquisition cost of the LSI chips in the product can be 
used to account for the contribution of the printed circuit 
boards, interconnects, chassis, and power. Another factor of 
2-3 accounts for the cost of making the product suitable for a 
severe environment. While seemingly rough factors, they check 
out surprisingly consistently across products in the minicom- 
puter and microcomputer range both in terms of available data 
and industry interview. 

Using these two factors and the neutral case of 50% 
annual growth for microcomputing devices which yields $5 
devices, a SEM2A module of six boards with two devices per 
board would have an acquisition cost of $450. Two modules would 
be needed in the core of the homogeneous architecture alterna- 
tive to be equivalent in performance with the airborne stan- 
dard heterogeneous architecture alternative under the assump- 
tions of that scenario. One module would be needed in the core 
of the homogeneous architecture alternative to be equivalent 
in performance with the CFA standard heterogeneous architecture 
alternative under the assumptions of that scenario. 
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This concludes the discussion of how the costing results 
were obtained. While not every case of the two scenarios was 
detailed, hopefully the reader qa.ined enough to understand how 
the costing results of Figure (9-7)were obtained. A narrative 
summary of these results would be put as follows. For air- 
borne applications, the rate of technological change and growth 
of general use of LSI microcomputing devices is great enough 
to offset any cost advantages of standardization of computers 
and software development and support tools even of the form, 
fit, and function type. The three significant areas of cost 
that manifest this are the acquisition cost, the operating and 
support costs, and the aircraft flyaway cost attributable to 
the computers. Even without the flyaway cost considered, the 
homogeneous case is the cost-effective alternative under both 
scenarios and all cases. If these results hinged on one con- 
dition, it would be the continued understanding of distributed 
computing and the continued development of the software to 
effect it. 
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Appendix A. 



GENERALIZATION OF COST ISSUES 



This section presents for the reader a narrative tutorial 
on the cost issues involved in systems engineering with LSI 
based circuitry, particularly microcomputing devices. A few 
controversial things should be immediately pointed out for 
the initiated reader as being conjectured by this report, and 
supported elsewhere. The first is that while useful to an 
extent, cost per gate or cost per bit may no longer be as 
relevant a parameter for systems engineering with microcompu- 
ting/microprocessor devices as cost per device plus cost per 
interconnect of devices (2-1) . Second, the cost of special 
hardening of a microcomputing/microprocessing device against 
radiation, shock, heat, and other environmental factors by 
the use of sapphire substrates, etc., may be overkill when its 
contribution to overall aircraft survivability is assessed. 

And finally, the actual cost contribution of software may not 
be minimized by adherence to standard computing devices nor 
even paramount when total systems engineering costs are con- 
sidered (specifically aircraft weight penalty from standard 
computing devices in this report's analysis). With these 
ideas brought forward, some tutorial cost generalizations will 
now be described. 

A. HARDWARE 

A key to the economic aspects of systems engineering with 
LSI circuitry based systems is in the associated manufacturing 
technology. Manufacturing technology is the means by which 
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something is fabricated by the producer. Typically any product 
will go through several stages of processing from raw material 
to finished system with value added at each stage. It is the 
technology which takes production through each of these stages 
that is called manufacturing technology. It can be embodied 
in the form of a more educated or trained labor force, new 
capital equipment capable of enhanced production, or an inter- 
action of the two. 

Because systems engineering with LSI circuitry is to a 
great degree influenced by semiconductor manufacturing tech- 
nology, a simplified version of the steps gone through to 
create a microprocessor/microcomputer based process control 
system will be presented. The steps are annotated with econ- 
omic "thumb rules," gained from personal interviews and liter- 
ature search, that generalize the cost issues involved in LSI 
circuitry systems engineering. All dollars are expressed in 
current year dollars. The steps are shown as sequential but 
in reality may overlap in time. 

The lowest common denominator sought as a measure for circuit 
design of an LSI device is the active element group (AEG) ; a gate 

for logic units, a bit for memory units. Measures of com- 
plexity and recurring device manufacturing cost are made 
parametrically on AEG counts. Figure A-lis a composite over- 
view of the trends in device complexity and recurring manu- 
facturing cost in the last several years for the silicon 
metal oxide semiconductor device technology. The description 
of the steps that follow will develop how Figure A ~1 is 
constructed. 
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YEAR 



Source- - Hittinger, William C. 

"Metal- Oxide -Semiconductor Technology" 
Scientific American, August 1973, 

Vol. 229, No. 2, page 28 

TRENDS IN LSI COMPLEXITY AND COST 
Figure A-l 
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COST/COMPONENT, cents 



The first step in the LSI manufacturing process however 
is not included in the computations to obtain Figure 
This first step is the creation of the circuit logic design 
and accounts for the major share of the non-recurring costs 
of production. In the case of an original design which works 
significantly into a semiconductor manufacturer's corporate 
strategy (like the Intel 8080, Motorola 6800, and Texas 
Instruments' 9900), the cost of this creative, labor inten- 
sive activity is generally in the millions of dollars, and 
one to two years of calendar time. For the 8080, 6800, and 
9900, the figure was probably around $5,000,000 each. A 
reasonable, although large, range for this non-recurring 
cost is from $100,000 to the few millions. The large vari- 
ance comes from a number of factors ranging from corporate 
financial structure, and marketing, to existing design tools. 
Separating out this latter factor as one which could be appli- 
cable industry wide, reveals two significant developments 
that have the potential of reducing this non-recurring cost. 
These are computer-aided-design, and the use of general cir- 
cuit design arrays that are customized in the final masking 
and diffusion steps (to be explained more fully later) . Some 
companies have reported out in the trade magazines reduction 
in calendar time for development of a logic design to 2-3 
months and a reduction in non-recurring cost of design into 
the tens of thousands of dollars from the hundreds of thousands 
of dollars. (A question which remains unanswered but will be 
addressed later is if the non-recurring cost of the design of 
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the testing procedures for these custom LSI chips has been 
included in this reduced non-recurring cost.) Being the 
first step in the process and particularly if tied heavily 
into the corporation's strategic planning, working out a 
logic design which later proves faulty, which has problems 
in production and testing, and which has missed the market, 
can quickly put a source of LSI circuits into financial 
straits. To a high level military budget planner, thinking 
in terms of hundreds of thousands of dollars or even a few 
millions of dollars may not be significant. We are numbed 
by large numbers almost daily. However, even a casual 
reading of a magazine like Business Week gives one an appre- 
ciation for how in a fiercely competitive business like 
semiconductors, risking and losing from a few hundred thou- 
sand dollars into the few millions of dollars and the con- 
current few months of time can set a corporate strategy on 
its head and leave companies as big as Texas Instruments 
trying to overcome the effects (9-6) . 

After the logic design has been worked out, the next step 
is drafting and documenting the design. This generally takes 
from 2-3 man-months. If computer-aided-design was used, this 
step can be a fallout of the actual logic design process. 

The next part of the process entails growing a very pure 
sausage-shaped silicon ingot. 
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The silicon raw material is a miniscule part of the cost. 
Other materials used are silicon-on-sapphire (SOS) (obviously 
more expensive in terms of raw material) , and most recently 
the use of GR-AS, Gallium-Arsenide. 

The ingot diameter is a crucial number. The diameter 
has grown from 1-2 inches to 3-4 inches, with 5-6 inches being 
the leading edge of the technology. Beyond 6 inches, while 
possible, creates warping problems when the ingot is sliced 
into wafers. The crucialness of increasing the ingot diameter 
is the multiplicative effect it has on the number of chips 
that can be created in one process set up. For example, the 
ratio of surface area on a 4-inch diameter ingot to one with 
a 3-inch diameter is simply 




4 * 

H (7) 
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16 
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or roughly 1.8 times the number of possible chips. Note how- 
ever that this ratio decreases as the ingot grows successively 
larger, another reason why expanding incrementally, by heavy 
capital investment, beyond a 6-inch ingot is considered very 
leading edge technology and very unlikely in the future. 

The next manufacturing phase is to slice the ingot -into 
wafers, each about 0.03 inches thick. 




The wafers are then sent through a masking and diffusion pro- 
cess anywhere from three to ten times. This process entails 
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miniaturizing and replicating the circuit design on the wafer. 
A photolithographic technique is used for masking. As minia- 
turization beyond optical resolution levels occurs, an elec- 
tron beam technique is used. Masking basically lays out the 
negative of the circuit pattern, and diffusion "etches" the 
pattern onto the surface of the wafer. (The generalized 
circuit array process mentioned earlier etches out several 
clusters of common circuit elements and these wafers are put 
"on-the-shelf . " A final masking and diffusion will connect 
up only those elements desired for the "customized" circuit 
design when a user orders it up. This customized design 
however must still undergo testing procedures developed for 
it and it alone.) 

The first, and most significant of three test points now 
occurs. The etched wafer is inserted into a test probe where 
some very simple tests are used to determine bad chips. The 
industry average wafer yield is only about 30-40%. For 
example, if a 4-inch diameter ingot is used and a 200 mil x 
200 mil (0.2 inch x 0.2 inch) chip is desired, the maximum 
number of chips per wafer that can be etched is a few less 
than 300. Hence, only about 100 are acceptable after this 
check point. Furthermore, that 30-40% wafer yield is the 
industry average. As a new device is being produced, wafer 
yield may be as low as 5% until an initial experience base 
has accumulated. (This initial base is estimated at 32 
wafer runs or about 10,000 "possible" chips . ) Learning occurs 
and the yield will eventually reach the 30% average, and for 
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some designs and in some companies, wafer yield may reach as 
high as 40-50% for a sustained run of wafers. However, for 
some logic designs or for some companies the industry average 
of 30% wafer yield might never be reached, particularly if 
the production run is not sustained over time. 

After going through the test probe and marking of the bad 
chips, the wafer is scribed, i.e., the wafer is cut up into 
individual chips. The bad chips are discarded and the good 
chips are sent to be packaged. Three methods are currently 
used to package the chips. The oldest method, the flat pack, 
has been largely replaced by the most prominent method, the 
dual- in-line (DIP) package. The third method, the chip 
carrier, is the leading edge packaging technology and will 
be discussed shortly. In the DIP, the chip is placed on a 
lead frame by a worker using a special machine and a microscope. 



The leads are bonded by pressure to the chip and to the pins. 
This is generally a labor intensive process and the cost of 
DIP packaging is considered as an increasing function of the 
number of pins (leads off the chip) , with 40 pins being the 
break point where the cost increase begins to become more 
severe. (This aspect is beginning to get more attention in 
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systems engineering with LSI chips.) Most semiconductor com- 
panies will send the chips overseas to be packaged and assembled 
into a product. The mounted chip is inspected for good con- 
nections. The industry average yield of good mountings is about 
80-90% of the number of chips that pass wafer yield. This 
yield is called the packaging yield. Returning to the example, 
that means 80-90 good chips (200 mil x 200 mil) from the 4- 
inch wafer at this point. A cap of ceramic or plastic is in- 
stalled on these good packages. For high reliability uses, 
the cap is hermetically sealed. The hermetic seal is the pri- 
mary reason given for the more expensive price, by a factor 
of 2-3 over commercial chips, of military temperature spec 
DIP's. For other uses the cap is molded on. The capped 
package is extensively tested at this point by automatic 
testing equipment. The ratio of good chips to the total in 
this final test yield is 80-90%. Continuing the example, 
that means about 64-81 good chips (200 mil x 200 mil) from a 
possible of 300 from a 4-inch wafer. 

The reader should at this point reflect on the 
philosophy for designing large systems in this report. As 
chips become larger and more complex, the design of this final 
test can approach that of the logic design of the chip itself, 
i.e., this non-recurring cost of final test design can be on 
the order of tens of thousands of dollars, if not into the 
hundreds of thousands of dollars. Even if computer-aided- 
design and final mask and diffusion customizing can reduce 
the non-recurring logic design cost, a non-recurring final 
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test design cost must still be incurred for every peculiar 
logic design conceived of. Computer generated tests can 
aid this process. An obvious cost advantage could be had 
by the user if this large test design non-recurring cost 
is spread over as many other users as possible. 

Because of the labor intensiveness of packaging, and its 
cost as an increasing function of pin count, some forms of 
packaging are being developed, other than the DIP, which lend 
themselves to easier productizing (interconnecting) from a 
chip set. One which appears in a couple of different forms 
is called the chip carrier. Using a completely automated 
procedure^ the LSI chip is suspended and encapsulated in a pin- 
less package. The leads are bonded to the chip and joined 
to only a solder point on the edge of the carrier. 

Up to this point what has been discussed is the manufac- 
turing process of logic design of packaged chips for a micro- 
processor/microcomputer device. In summary, the non-recurring 
manufacturing cost of logic design is from the tens of thou- 
sands of dollars into the few millions of dollars. The same 
magnitudes are true for the non-recurring cost of logic design 
testing procedures. The recurring costs of packaged chip 
manufacturing have followed the trend in Figure fV-1) and are 
currently between about .01-. 1C per active element group. That 
means that for a microprocessor chip on the level of complexity 
of the Intel 8080A, about 4,000 gates per chip, the recurring 
cost of manufacturing for a sustained run is between about 
$.40 to $4.00 per chip with a selling price around $15-20.00. 

A military temperature spec chip based on a sampling of price 
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lists is about 2-3 times that price. A chip of the complexity 
of the 16 bit word length TI 9940, a recently announced single 
chip microcomputer of about 10,000 gates, including 1-2,000 
memory bits and I/O points, would have a recurring manufac- 
turing cost of up to about $10.00 per chip. However, the 
selling price, as initially guessed by competitors, is at 
about $500.00 for the TI 9940 because Texas Instruments will 
still be amortizing the non-recurring costs and still be coming 
down the experience curve. 

The area to be addressed now is the process of going from 
an LSI chip set to a finished microcomputer product. This 
process is best conceived of as involving three stages, inter- 
connecting the packaged chips to a board, interconnecting the 
boards to accommodate for power, signal, and ground, and 
finally, interconnecting boards into a product case like an 
ARINC Air Transport Rack (ATR) or a Naval Standard Elec- 
tronics Module (SEM2A) . There is a wide variety of methods 
to accomplish each of these steps and it is probably fair to 
say that these steps are not as amenable to as rapid a pace of 
technological change in manufacturing technology as is the 
fabrication of the packaged LSI chip. Again, it is volume 
that will determine the amount of automation that will exist 
in the manufacturing process. Systems engineering trade-offs 
are made between performance, and reliability/maintainability 
which impact the manufacturing technology of productizing 
from chip sets, rather than the manufacturing technology im- 
pacting the systems engineering as with the chip making process. 
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The non-recurring cost of product design from chip sets 
is on the order of thousands of dollars into the few hundreds 
of thousands of dollars but again, possibly into the few 
millions of dollars for some corporate strategy intertwined 
items like the first programmable calculators or militarized 
processors and computers like the AYK30 , LSI11M, PDP11/34M, 
AYK14, and ROLM products. 

The parameter for recurring cost estimation and also for 
reliability /maintainability measurements when productizing 
(interconnecting) an existing LSI chip set is the number of 
connections or contacts that have to be made between chips 
and supporting active element groups like power, ground, and 
signal connections within the product. Although the contri- 
buting failure mechanisms of LSI chips to the product are 
being explored, it is the interconnects that are most signifi- 
cant in the failures of a product and that may reflect the 
reliability overkill of the LSI chip. 

These recurring costs for a sustained production run 
range from 5C to IOC per connection and slightly more depend- 
ing on the interconnect method used, production volume, and 
automation level of manufacturing. A few of these inter- 
connect methods will be described. Following this will be a 
description of three techniques that go directly from chip 
carriers (vice packaged chips) to product. When projecting 
to a VSTOL program with the concept definition and validation 
occurring in about the 19 81.-19 85 time period, it will probably 
be one. of these three techniques that will end up as the 
interconnect technique. 
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Interconnection of chips in computers in the early 1970's 
was accomplished with point-to-point wiring of chips mounted 
on molded plastic blocks throughout the system. This is labor 
intensive but provides the ultimate in flexibility and would 
be now used primarily for breadboarding of prototypes or low 
volume products that don't justify the capital expense of 
automated fabrication machinery. More common today is the use 
of printed circuit boards (PCB's), which have solder runs to 
provide the means of current conduction. The DIP's are pressed 
manually or automatically into female connectors aligned on the 
PCB. These boards, called daughter boards, still must be con- 
nected into a backplane, called a mother board as in Figure 




Originally, the mother boards were metal backplanes and had 
rows of female post connectors into which male edge connectors 
on the daughter boards were plugged. Posts on the mother 
board served as leads into which hand wire-wrapping (more than 
IOC per connection) or automated wire wrapping (about IOC per 
connection) were accomplished on the reverse side of the back- 
plane. The wire wrapping provides flexibility in that the 
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board can be rewrapped if a daughter board is updated. In very 
large quantity designs where flexibility is not so important, 
a multilayer printed circuit epoxy-glass or fabric mother board 
is now used. The printed circuit daughter boards, often two- 
sided, are pressed into the edge connectors on the mother 
board, also often two-sided. The printed circuits on the 
multilayered mother board provide the interconnects via posts 
of selected lengths that run through the mother board layers. 
Some mother boards still retain a few posts for wire wrapping 
of power, signal, and ground points. Others don't, relying 
instead on flat-wire edge connectors. The cost per connection 
on the multilayer printed mother boards is about 5-8C, depend- 
ing on several things such as the number of layers, remaining 
wire wraps, etc. 

The number of interconnects per edge connection on the 
PCB has increased from a few to several dozen as the level of 
chip integration has increased. Hence, the amount of force 
required to insert a daughter board into a mother board has 
increased considerably. This has led to Zero Insertion Force 
(ZIF) connectors. There are several ZIF designs. They re- 
quire no force for insertion because all the female connectors 
are initially free of resistance. Once the PCB board is in 
place, then a mechanical action like a lever or machine screw 
is actuated to close all the female contacts simultaneously. 

The latest form of the ZIF connector is to dispense with 
the mother board idea all together and stack two-sided daughter 
boards via ZIF connectors that themselves act as active elec- 
tronic elements (Figure A-3) . 
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ZIF CONNECTORS 
Figure A -3 
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The trend, as can be seen by the ZIF interconnect technol- 
ogy, is toward making the interconnects themselves active 
electronic elements. Referring back to the chip carrier con- 
cept, in some cases the chip carriers are automatically placed 
on cold solder points, which themselves have been automatically 
placed on a ceramic layered PCB. The entire arrangement is 
refluxed in a kiln. The chips line up with the solder points 
as the solder cools. Figure (A-4) shows one board of SEM2A 
size module productized in this manner. Up to six of these 
boards would be joined with ZIF connectors in the SEM2A module. 

Another type of chip carrier package stacks several carriers 
together with the stacking frame acting as active electronic 
elements in the overall product (Figure A-5) . 

These are two of the more advanced chip carrier concepts 
used to create a product out of a chip set. The cost per 
connection for interconnecting the chip carriers as described 
above is projected at slightly more than IOC per connection in 
vo lume . 

Another, albeit somewhat more exotic, technique which has 
particular meaning with regards to optical fiber data trans- 
mission technology and avionics, is the flexible circuit. Up 
until now, each of the interconnect arrangements described 
was still somewhat conventional in that chips were connected 
to boards, boards were interconnected, and these were placed 
into a card cage with a metallic ATR or SEM2A sized box and a 
control panel. The flexible circuit idea dispenses with the 
idea of boxing chips on boards. It involves taking several 
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SEM2A SIZED REFLUX SOLDER BOARD 
Figure A - 4 




STACKED CHIPS CARRIERS 
Figure A - 5 
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chip packages, or as is more likely by 1985, several chip 
carriers, each with its own convection cooling vanes, and 
interconnecting them to a flat, flexible bundle of wire, or 
a flat fiber optic bundle (Figure A-6). (The arrangement 
would look very much like the sugar drop candies affixed to 
paper tape, popular with children a generation or two ago.) 

The flexible circuit would weave its way through the aircraft 
airframe interconnecting with sensors, power, and ground as 
appropriate (in much the same way as human nerve fibers weave 
their way through the body) with no metallic housing (ATR or 
SEM2A) required. Servicing would not require "neurosurgery" 
level expertise in that built- in-test (BIT) programs could 
isolate out sections of the flexible strip for replacement 
via snap connectors located every so often. All that would 
have to be known for service would be an hierarchical level 
model of the data flow within the aircraft, much like the one 
described in this report, since the BIT would isolate to a 
section of flexible circuit. 

The two former chip carrier systems are still slightly 
above the IOC per connection figure. The latter flexible cir- 
cuit idea is only in the conceptual stage and no cost inform- 
ation is available. The key to the ability of all three of 
these advanced techniques to be able to compete cost-wise with 
existing interconnect techniques is in whether or not demand 
for them will be of such a volume that their automated manu- 
facturing technology investment is justified. Based on the 
military computer system numbers generated in this report, it 
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Figure 



is doubtful whether the military alone could foster the neces- 
sary volume. Rather, as postulated throughout this report, the 
military will have to get in on the commercial market. 

A good example of how the military spec is already adjust- 
ing to commercial market forces is the coating used on connec- 
tions to combat corrosion on interconnect surfaces. Gold 
plate over nickel is used. The mil-spec was 50y in. gold over 
100y in nickel but was lowered to 30y in gold over 50y in 
nickel. The latter is the thickness already used in certain 
types of commercial computers. Besides corrosion, temperature 
extremes, large vibrations, excessive moisture and radiation 
are also considered, in view of the military specification 
structure, as requiring special handling for a military compu- 
ter. The totality of these areas when demonstrated in a mil 
spec device or- complete computer creates about a factor of 2-3 
more in the price of a military computer when compared to its 
commercial counterpart. Continuance of that factor is ques- 
tionable as basic devices and products find commercial use 
in high reliability areas like steel furnace control, nuclear 
power plant control, automobiles, general aviation, etc. 

B . SOFTWARE 

There are three discernible parts to the avionics software 
cost issue, and the software cost-estimating problem. The 
first part is the cost associated with the applications soft- 
ware creation. In avionics this is the Operational Flight 
Program (OFP) . The second part is the software development 
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and support tools used for creation of the applications soft- 
ware. These are the compilers, debuggers, editors, etc. The 
third part is the aircraft systems simulators, the mock ups 
which are used to simulate an aircraft in flight, to test out 
the OFP. To place the software cost issue in perspective, 
interviews with industry indicate that as much as 95% of soft- 
ware cost is in the development and support tools and systems 
simulators. Literature search indicates that cost estimating 
for the estimated remaining 5% is more structured with regards 
to parametric, or top down, techniques and established data 
bases. The cost estimating of development and support tools 
and simulator systems is left to the engineering, or bottom 
up method, and is dependent on the decision at hand, the 
actual computer system under review, and the systems already 
in place. 

The systems simulators are not considered as a differen- 
tial cost element in this report as they are created on param- 
etric characteristics of the aircraft and the actual computer 
architecture of the avionics system is transparent to them. 

The differential cost elements with respect to the avionics 
computer system architecture are the software development and 
support systems and the applications software creation. 

These two cost elements are important to the economic analysis 
of this report because the worth of a standard computer family 
is most often argued for in light of the savings generated by 
software commonality across several applications. The software 
costing in this report will be framed around exploring the 
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validity of that argument in light of possible rates of growth 
of use of a standard computer family, possible rates of growth 
of technology embodied in computing devices in the commercial 
world, and the effects on aircraft airframe cost of the avion- 
ics computing system. 

Of the two differential software cost areas, OFP creation, 
and development and support tools, generalization of the cost 
issues and methods of the former will be addressed first (a 
costing method used in contracting and a parametric technique 
will be described from the literature) . The latter will then 
be addressed based on trends discerned by this author from the 
literature. 

Aircraft contracts with hardware and software procurement 
bundled together cost the applications software development 
as a percentage of the airframe engineering full scale devel- 
opment man-hours. The percentage is a negotiated figure 
based on the corporate history of both the buyer and seller 
and may or may not include the cost of the development and 
support tools, and systems simulators. Because corporate 
costing history is proprietary and because this report is 
meant to generate some independent estimates, a parametric 
technique was used, best described by reference (A2) . This 
technique will be paraphrased for the reader. In the process 
of doing so it will be highlighted with some additional current 
thoughts from the literature on the applications software life 
cycle and management. An annotated bibliography is also in- 
cluded at the end of this report for the reader specifically 
interested in this area. 
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The parametric technique of reference (A2 ) is based, as 
most are, on the parameter of software program size as 
measured by number of source or object instructions. Often 
the instruction count is weighted by the degree of difficulty 
or complexity inherent in the creation of the instruction 
type and whether the programming routine is old or new (A3). 

In the technique used for this report an estimating relation- 
ship coefficient will embody these ideas of degree of diffi- 
culty and old or new for a certain class of software programs. 

Cost is generally expressed in man-months of effort vice 
dollars so that an individual software vendor's cost per man- 
month can be applied when the technique is used for planning, 
budgeting, or contract negotiations. 

After sizing the software in terms of man-months for 
development, the next step in the estimating technique is to 
time phase the man-months over the calendar time of the soft- 
ware development project. The idea behind this phasing is to 
generate a man-loading curve (man-months per month) for pro- 
ject management. Once this curve has been generated, incre- 
ments of man-loading resource are spread across the various 
project activities such as documentation, project management, 
programming, etc. 

The entire process can be framed using the figure (A-7) 
from reference (A2) . The technique begins by using the follow 
ing relationship to estimate man-months for applications soft- 
ware development effort. 

MM = C ( I ) P • n f . 

o,s 1 1 
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SOFTWARE LIFE CYCLE MANLOADING 
Figure A - 7 



whore 

MM - man-months of development effort 

C a coefficient estimated from a data base of like projects 

I - the count of source or object instructions in the 
°' applications software 

P a power estimated from the data base of like projects 

f. - multiplicative factors that come from a stratification 

of the data into groups such as; developed on host 
computer vs. target computer , developed on a time 
share system vs. a batch system, etc. 

As seen from figure (A-7) , development is only part of the appli- 
cations software life cycle. It has come to be sub-divided 
itself into three phases; analysis and design, code and debug, 
and module and systems test and integration. Literature search 
and interviews support the conventional wisdom that the split 
of effort between these three phases of development, i.e., the 
man-loading split, is 40%, 20%, 40% respectively (A4) . 

Once the number MM has been estimated, the technique takes 
the following quotient to determine the total man-months of 
effort in the applications software life cycle, i.e., the total 
area under the curve of figure (A-7) . 

„ _ MM 

K 0.39 



K - total man-months of effort for life cycle of applications 
program 

The technique then describes the curve by 
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where 



0.667 

t_. = I / (99.25+2.33IO ) 

D o' 

Y - man-months/month 

tp - natural development time for an applications program of 

I object instructions 
o J 

2 

The major point of the technique is that (K/t ) is a 

D 

constant based on instruction count, and that it is not possi- 
ble to compress the natural development time by adding man- 
months of effort. Rather it is hypothesized, supported by 
independent sources (A5,A6,A7), that there exists a natural 
time and man-loading curve for a particular sized program. In 
the words of Brooks in his classic essay "The Mythica] Man- 
Month", adding man-months of effort to an applications soft- 
ware development project which is off schedule makes it later, 
particularly if as pointed out in (A3) , it is added late and 
tentatively. Preliminary work by others shows that the dis- 
tribution of K, the total man-months of effort, by a 39%K to 
development, 55%K to transition to the user, and 5%K in steady 
state maintenance is reasonable within a few percentage points 
(A9) . 

Reasons for the shape of the man-loading curve in figure 
(A-7)can be found in another reference (A10) which reports that 
the error profile of an applications program can be character- 
ized by the saw-tooth of figure (A-8). 

The cause of this saw-tooth effect is intuitively pleasing 
and plausible. When a user begins use of the applications 
software during transition, it is put through a wider range of 
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Figure A-8. Error Reduction Process Showing Discontinuities at 
Each New Phase. 
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data, on the target machine, and possibly a more taxing 
environment than that of the development lab. Bugs are dis- 
covered and worked out that weren't discovered in the more 
benign environment of the development lab. 

This technique of reference (A2), paraphrased above, will 
be used to cost the navigation and ballistics portion of the 
VSTOL OFP analyzed in the first part of this report. It will 
also be used to address the issue of development and support 
tool cost and software maintenance cost. A literature search 
in this other area of software cost impressed this author of 
the point that as with the minicomputer, the microcomputer is 
undergoing a burgeoning of software development and support 
tools. Several forms of these tools are available. 

One approach is to purchase outright a software develop- 
ment system targeted for the particular microcomputer device 
for each applications programmer. These systems are available 
from both the parent company and the software tools houses 
and require the initial capital investment and training work 
up. Although the systems vary as to compatibility and cost, 
a development system with CRT, key board, a higher order 
language (HOL) like FORTRAN, PLM, or PASCAL, a set of pro- 
gramming aids, and a read only memory (ROM) programmer can be 
had in the $25,000 range. 

Another approach is to lease time from the increasing num- 
ber of microcomputing development commercial time share sys- 
tems capable of handling all of the various device types. 

These firms make the capital investment in the development 
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and support system tools and then lease the time, a process 
modeled by the same S • N ^ CNR + CR • N inequa 1 i ty of the first 
part of this report. A current quoted figure is $1,000 per 
month for lease of one terminal that provides any one of 
several HOL's for any one of several microprocessor /micro- 
computer devices. The terminal would have a CRT, and a basic 
set of programming aids. 

A third approach is to buy outright a development system 
capable of handling several different microprocessor /micro- 
computer devices. Although no quotes were available, these 
systems would start at $100,000. 

A final approach considered is to create the development 
and support tools for the target microcomputing devices and 
the input/output structure for each application to run on a 
main frame host machine. This would be in the form of com- 
pilers, code generators, assemblers, debuggers, linkers, 
loaders, etc. The data generated by the Computer Family 
Architecture report will be used in this report in an order 
of magnitude way to address the costing issues of this method 
of supporting software with respect to the others. As an 
example of the magnitudes involved in this method, the CFA 
report estimated about $4.9M for a CMS 2 compiler for the CFA 
candidate machine. 
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